From nobody Thu Jun 1 04:57:42 2017 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C456912EBA3 for ; Thu, 1 Jun 2017 04:57:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, 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 miqGLtPsEUNk for ; Thu, 1 Jun 2017 04:57:39 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB7B912EB9E for ; Thu, 1 Jun 2017 04:57:38 -0700 (PDT) X-AuditID: c1b4fb25-73a9f9a0000055fe-7f-593001302d71 Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.183.87]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 06.EA.22014.03100395; Thu, 1 Jun 2017 13:57:36 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.30]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.03.0339.000; Thu, 1 Jun 2017 13:55:51 +0200 From: Christer Holmberg To: Christer Holmberg , Peter Thatcher , "ice@ietf.org" Thread-Topic: [Ice] Peter's review of ICEbis - Much of the spec is much more complicated than it otherwise would be because a media stream has more than one component. Thread-Index: AQHS2EcFiI1CctLCKk6poKZrQK4FhKIPF/UAgACJAQCAAF0IAA== Date: Thu, 1 Jun 2017 11:55:51 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.4.170508 x-originating-ip: [153.88.183.146] Content-Type: multipart/alternative; boundary="_000_D555DC1A1D9F6christerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprHIsWRmVeSWpSXmKPExsUyM2J7uK4Bo0GkwayNJhbfLtRaXFv+mtWB yWPBplKPJUt+MgUwRXHZpKTmZJalFunbJXBlXL55gbngjltFz/537A2Mt627GDk5JARMJB7s 28YKYgsJHGGU+NUc08XIBWQvYpR4N+kJexcjBwebgIVE9z9tkBoRgTqJDcdvsoPUCAusYpTY MfU0M4gjIrCaUeL95ausEFVOErM/7QezWQRUJH5dPMIEYvMKWEu8+/uDCWLDFkaJRxsOsoJs 4BSwkdg/CewiRgExie+n1oDVMwuIS9x6Mp8J4lIBiSV7zjND2KISLx//A2sVFdCTeLffEyKs JPFjwyUWiNYEie3bjkKtFZQ4OfMJywRGkVlIps5CUjYLSRlE3EDi/bn5zBC2tsSyha+hbH2J jV/OMkLY1hLPVjxmR1azgJFjFaNocWpxUm66kbFealFmcnFxfp5eXmrJJkZgrB3c8lt1B+Pl N46HGAU4GJV4eNm/60cKsSaWFVfmHmKU4GBWEuFN+wwU4k1JrKxKLcqPLyrNSS0+xCjNwaIk zuu470KEkEB6YklqdmpqQWoRTJaJg1OqgdGIrz9a8Mu7PyzpO+8+qrQteV7FXLBun//M5c8M DHY0s/wRP/g9p6Ip5YPb46bg8NC2wMVfr29+cPre82mFfcqfX6443BpoxrdopeKrZyalMSpX 3TesVt7N5SBbzPX+v3vWBFMPFbd5W+6LN7F3P5SsWK1w9KxaVbfhf3Yt+WWzP7xa35A6z1KJ pTgj0VCLuag4EQD0sbdtsQIAAA== Archived-At: Subject: Re: [Ice] Peter's review of ICEbis - Much of the spec is much more complicated than it otherwise would be because a media stream has more than one component. X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jun 2017 11:57:41 -0000 --_000_D555DC1A1D9F6christerholmbergericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, A couple of things to keep in mind if we want to remove the component conce= pt. First, a search for =93component=94 gives 95 hits, and the usage is spread = out all over the document. It would be quite a big task to remove it. We co= uld of course recommend to use use multiple streams instead of multiple com= ponents, but one would still have to support it. Second, would removal of components be backward compatible with legacy ICE = devices? Regards, Christer From: Ice > on behalf of = Christer Holmberg > Date: Thursday 1 June 2017 at 09:22 To: "pthatcher@google.com" >, "ice@ietf.org" > Subject: Re: [Ice] Peter's review of ICEbis - Much of the spec is much more= complicated than it otherwise would be because a media stream has more tha= n one component. Hi, >I think it's OK if we completely special case this... special case. Just = say something like "ancient endpoints which do silly things like not multip= lex RTCP and RTP >over the same media stream will use two media streams and in this case the= streams are not useful unless both succeed". > >What else is there to say? Currently section 6.2.5.4 says the following: "If there is a valid pair for each component in the VALID LIST, the state of the check list is set to Succeeded." Now, if we REMOVE (I assume that is what you are suggesting?) the whole com= ponent concept that text would obviously go away. But, at the same time we = remove the requirement to have a valid RTCP- and RTP pair in order for a CH= ECK LIST state to be set to Succeeded. Regards, Christer On Sun, May 28, 2017 at 11:44 PM Christer Holmberg > wrote: Hi, > - Much of the spec is much more complicated than it otherwise would be be= cause a media stream has more than one component. Would it make sense > to define a check list as representing a single component of a single med= ia stream rather than multiple components? That would make the rules and s= tates around check lists much more simple. I have been thinking the same thing :) However, in that case I think we need to talk about certain media streams b= eing =93dependent" on each other, and that checks for both streams (e.g., o= ne RTP stream and one RTCP stream) must succeed in order to the streams to = be used (unless BUNDLE is used, of course). Regards, Christer --_000_D555DC1A1D9F6christerholmbergericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <057368545B9857478415A85239B84176@ericsson.com> Content-Transfer-Encoding: quoted-printable
Hi,

A couple of things to keep in mind if we want to remove the component = concept.

First, a search for =93component=94 gives 95 hits, and the usage is sp= read out all over the document. It would be quite a big task to remove it. = We could of course recommend to use use multiple streams instead of multipl= e components, but one would still have to support it.

Second, would removal of components be backward compatible with legacy= ICE devices?

Regards,

Christer

From: Ice <ice-bounces@ietf.org> on behalf of Christer Holmb= erg <christer.holmberg= @ericsson.com>
Date: Thursday 1 June 2017 at 09:22=
To: "pthatcher@google.com" <pthatcher@google.com>, "ice@ietf.org" <ice@ietf= .org>
Subject: Re: [Ice] Peter's review o= f ICEbis - Much of the spec is much more complicated than it otherwise woul= d be because a media stream has more than one component.

Hi,

>I think it's OK if we completely special case this... = special case.  Just say something like "ancient endpoints which d= o silly things like not multiplex RTCP and RTP
>over the same media stream will use two media streams and in this = case the streams are not useful unless both succeed".  
>
>What else is there to say?

Currently section 6.2.5.4 says the following:
   "If there is a valid pair =
for each component in the
   VALID LIST, the state of the check list is set to Succeeded."
Now, if we=
 REMOVE (I assume that is what you are suggesting?) the whole component con=
cept that text would obviously go away. But, at the same time we remove the=
 requirement to have a valid RTCP- and RTP pair in order for a CHECK LIST s=
tate to be set to Succeeded.

Regards,

Christer



On Sun, May 28, 2017 at 11:44 PM Christer Holmberg <christer.holmberg@ericsson.c= om> wrote:
Hi,

> - Much of the spec is much more complicated than it otherwise wou= ld be because a media stream has more than one component.  Would it ma= ke sense
> to define a check list as representing a single component of a si= ngle media stream rather than multiple components?  That would make th= e rules and states around check lists much more simple. 

I have been thinking the same thing :)

However, in that case I think we need to talk about certain media stre= ams being =93dependent" on each other, and that checks for both stream= s (e.g., one RTP stream and one RTCP stream) must succeed in order to the s= treams to be used (unless BUNDLE is used, of course).

Regards,

Christer
 --_000_D555DC1A1D9F6christerholmbergericssoncom_-- From nobody Thu Jun 1 05:53:05 2017 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10A6012EBD0 for ; Thu, 1 Jun 2017 05:53:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 7oq2WBAdpItR for ; Thu, 1 Jun 2017 05:53:02 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 520D1120454 for ; Thu, 1 Jun 2017 05:53:02 -0700 (PDT) X-AuditID: c1b4fb3a-6e3519a000004a6a-51-59300e2cb7d0 Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.183.78]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id FA.FA.19050.C2E00395; Thu, 1 Jun 2017 14:53:00 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.30]) by ESESSHC020.ericsson.se ([153.88.183.78]) with mapi id 14.03.0339.000; Thu, 1 Jun 2017 14:49:57 +0200 From: Christer Holmberg To: Christer Holmberg , Peter Saint-Andre , Peter Thatcher , =?iso-8859-1?Q?Ari_Ker=E4nen?= CC: "ice@ietf.org" Thread-Topic: ICE Session definition [was: Trickle ICE review] Thread-Index: AQHS2tWS71IISIKkIkC/8+ijqJUCKA== Date: Thu, 1 Jun 2017 12:49:57 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.4.170508 x-originating-ip: [153.88.183.16] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <7877515D5747E74185BB5BAC6075E11D@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupjkeLIzCtJLcpLzFFi42KZGbHdT1eHzyDS4P4hRYtvF2otri1/zWpx bE8/swOzx4JNpR5Llvxk8pi75wVzAHMUl01Kak5mWWqRvl0CV8bBq9fZC+ZwVTQ83s7YwLid o4uRk0NCwERi6ewd7F2MXBxCAkcYJf4uOcwE4SxilDj38hdjFyMHB5uAhUT3P22QuAhI0flf y5lA4swCihIv96qBDBIWsJJ49/AqE4gtImAv8bS5kR3C1pPYMW0/2BgWARWJq93mIGFeAWuJ G+93sYDYjAJiEt9PrQFrZRYQl7j1ZD4TxG0CEkv2nGeGsEUlXj7+xwoyRhRo5Lv9nhBhRYmd Z9uZIVr1JG5MncIGYVtLNExfAjVSW2LZwtfMEGsFJU7OfMIygVF0FpJts5C0z0LSPgtJ+ywk 7QsYWVcxihanFhfnphsZ6aUWZSYXF+fn6eWllmxiBMbSwS2/rXYwHnzueIhRgINRiYc35Lt+ pBBrYllxZe4hRgkOZiUR3lZGg0gh3pTEyqrUovz4otKc1OJDjNIcLErivA77LkQICaQnlqRm p6YWpBbBZJk4OKUaGOdI/jl6/X7u9ptxEbvE38+atF8rL0lzv82ZW7zFhkucV1iWHeloX1LW vlStXOq91uU7a60+u5q4XNH0+B5r/othf8Ssp95mD3P43ihcCD3Hfe/6zVd+t79YlPLY8jaY JeypD04w2+dqP/VjiZyBlOWB72bRKft27U5Q2jY5QsYh9MYZnsMZakosxRmJhlrMRcWJAOTa IuehAgAA Archived-At: Subject: [Ice] ICE Session definition [was: Trickle ICE review] X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jun 2017 12:53:04 -0000 Hi, I=B9ve created a PR, which adds the =B3ICE session=B2 definition to 5245bis= . https://github.com/ice-wg/rfc5245bis/pull/37 Regards, Christer On 30/03/17 20:53, "Ice on behalf of Christer Holmberg" wrote: >Hi, > >Perhaps we could say something like "re-start or once all candidates have >been released", or something like that... We seem to agree, so it's just >about wording :) > >Regards, > >Christer > >-----Original Message----- >From: Peter Saint-Andre [mailto:stpeter@stpeter.im] >Sent: 30 March 2017 20:42 >To: Peter Thatcher ; Christer Holmberg >; Ari Ker=E4nen >Cc: ice@ietf.org >Subject: Re: [Ice] Trickle ICE review > >On 3/30/17 9:45 AM, Peter Thatcher wrote: >> Ah, I see what you mean now. >>=20 >> In that case, could we just define "ICE session" as the something like >> "stuff until the next ICE restart or the termination of all ICE >> activity by this agent"? > >Right, there's no "ICE session termination" message, so that'll have to >do. > >Peter > >_______________________________________________ >Ice mailing list >Ice@ietf.org >https://www.ietf.org/mailman/listinfo/ice From nobody Thu Jun 1 17:33:41 2017 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E51AC129482 for ; Thu, 1 Jun 2017 17:33:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 cIJmCmH-mVnY for ; Thu, 1 Jun 2017 17:33:38 -0700 (PDT) Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 359D612947E for ; Thu, 1 Jun 2017 17:33:38 -0700 (PDT) Received: by mail-oi0-x22a.google.com with SMTP id w10so74171332oif.0 for ; Thu, 01 Jun 2017 17:33:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=W8yHHX5k2qEkc3ZnCe1WTw1JE9lafRMvMz7m7wlBCuI=; b=iu32z3SlzVl9NV4w5lud3M8ULmVYfy5I8n/kb0KV5PnUgIsZHKG8eynn9Zg3CdYgLk hJMVETAikBNpzm62OVtW0r89n2a7sbn6+MaYZS1IgeXirt1UeY8K9sMnWOfjNqjpDidE ymo550m/vFnkExdr2PBjW/1CPHjOzQ4xqpx2tsw6wbmnnRgywqCYzNIMM8H6bxZUChs6 EZfs0BestcJ4hhra1USFepRQ9V0PX0zjQW3657hcP1FRWszBlFTb6hyQB0QNjsXacb7W CivAAb9vmVYAHSEQG9CA23VsZdlOr5X3CLGokUNs95xcyjaM9T3mSJ51t1la17AID4qz j09Q== 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=W8yHHX5k2qEkc3ZnCe1WTw1JE9lafRMvMz7m7wlBCuI=; b=sELqlfX9IBpimMXgd6d9kOiabZvU2BUgFiwG+QA/egOlpM83j7mWn3XZORKtmlCbvb H+TkBMgL4nG1z0hy1k32VRFTnzuDGnsC2hFPpPrg0DcdgaEJyvrU6pe1Wljl0x6M7gHE hvm4lkbcS1PMAYP/ZstE3U2yOR0e2SENU9h2NJhbq2aaTwqi5mQAcDJucA/zItF9VLW7 9id/m4iVGslbRnxzklN36TVoMEZZjJ3LP9Yjup8bO3BHa08xuEOSN5OilIBREPA6S29D 9oX7gMcleRAyGj5x4mpS8tM8Truht3+XOY9DAJuPvM9ABhDus0m33zHWlyM8hy+O9Xx0 Eo1g== X-Gm-Message-State: AODbwcAftksnL/U7FxdXTYo+Hu3IWtpnL6fqQecJePk2Vka6HBj9o84n 6IFLriFRQYD5nNqPM91CWcBjZMOZ19/LrGY= X-Received: by 10.202.206.193 with SMTP id e184mr2744886oig.91.1496363617537; Thu, 01 Jun 2017 17:33:37 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Peter Thatcher Date: Fri, 02 Jun 2017 00:33:27 +0000 Message-ID: To: Christer Holmberg , "ice@ietf.org" Content-Type: multipart/alternative; boundary="001a113d2e72e128710550ef4d30" Archived-At: Subject: Re: [Ice] Peter's review of ICEbis - Why do we model valid candidate pairs as a separate list of separate candidates from the normal check list? X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2017 00:33:40 -0000 --001a113d2e72e128710550ef4d30 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable If it's not in any check list, then why not just add it to a check list in the Succeeded state? On Wed, May 31, 2017 at 11:20 PM Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > I need to take one step back. > > Keep in mind that pairs in the VALID LIST do not necessarily exist in any > CHECK LIST. > > See section 6.2.5.3.2. > > Regards, > > Christer > > From: "pthatcher@google.com" > Date: Thursday 1 June 2017 at 04:20 > To: Christer Holmberg , "ice@ietf.org" < > ice@ietf.org> > Subject: Re: [Ice] Peter's review of ICEbis - Why do we model valid > candidate pairs as a separate list of separate candidates from the normal > check list? > > What's the different between "valid" and "succeeded"? > > > On Sun, May 28, 2017 at 11:50 PM Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > >> Hi, >> >> > - Why do we model valid candidate pairs as a separate list of separate >> candidates from the normal check list? >> > Why not just say that some candidate pairs are valid. Why have this >> list of them? Seems like we could remove the concept. >> >> This is related to an e-mail I sent some time ago, where I asked whether >> we really need all states etc, and even suggested we could remove some o= f >> it. However, I then decided not to do it, because it could end up in a r= eal >> mess. >> >> But, related to your question, when I had a look at it I was thinking >> that =E2=80=9CVALID=E2=80=9D could just be a candidate pair state value,= rather than a >> separate list. >> >> Regards, >> >> Christer >> >> >> >> --001a113d2e72e128710550ef4d30 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
If it's not in any check list, then why not just add i= t to a check list in the Succeeded state? =C2=A0

On Wed, May 31, 2017 at 11:20 PM Christer Holmbe= rg <christer.holmberg@= ericsson.com> wrote:
Hi,

I need to take one step back.

Keep in mind that pairs in the VALID LIST do not necessarily exist in = any CHECK LIST.

See section=C2=A06.2.5.3.2.

Regards,

Christer

From: "pthatcher@google.com" <pthatcher@google.com>
Date: Thursday 1 June 2017 at 04:20=
To: Christer Holmberg <christer.holmb= erg@ericsson.com>, "ice@ietf.org" <ice@ietf.org>
Subject: Re: [Ice] Peter's revi= ew of ICEbis - Why do we model valid candidate pairs as a separate list of = separate candidates from the normal check list?

What's the different between "valid" and &qu= ot;succeeded"? =C2=A0


On Sun, May 28, 2017 at 11:50 PM Christer Holmberg <christer.h= olmberg@ericsson.com> wrote:
Hi,

> - Why do we model valid candidate pairs as a separate list of separate= candidates from the normal check list?=C2=A0
>=C2=A0Why not just say = that some candidate pairs are valid.=C2=A0 Why have this list of them? =C2= =A0 =C2=A0Seems like we could remove the concept.

This is related to an e-mail I sent some time ago, where I asked wheth= er we really need all states etc, and even suggested we could remove some o= f it. However, I then decided not to do it, because it could end up in a re= al mess.

But, related to your question, when I had a look at it I was thinking = that =E2=80=9CVALID=E2=80=9D could just be a candidate pair state value, ra= ther than a separate list.

Regards,

Christer


=
--001a113d2e72e128710550ef4d30-- From nobody Thu Jun 1 17:35:49 2017 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC76C129AE3 for ; Thu, 1 Jun 2017 17:35:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 JgpuONR07Yn7 for ; Thu, 1 Jun 2017 17:35:46 -0700 (PDT) Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 030561298BA for ; Thu, 1 Jun 2017 17:35:46 -0700 (PDT) Received: by mail-oi0-x231.google.com with SMTP id o65so49503765oif.1 for ; Thu, 01 Jun 2017 17:35:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=Z/HOj+g02ByKe160Z92uXGNhazie9qY974B0HJkNHLc=; b=K5BibBcyteNcIsgMMPzVcYKlfEhXkF7WP2doIVxB1/u7BfEmXGiG3i+Jih1p6UeiGf Wah0n/J3sVqb2gcPluCZKY7hAbfSi1jXd/Rko9ZpC75ueeMu/2FZ4oomKNa8Jo3lW1IC hyHIXuE9qFTSvfS8o0wnqhznKv2Phfbj5we+hSP4VLqRFvaPYKRLQll75tnOVeCnaIrJ I9ommQ02Mryk5od9oM9SUiTa3YIRfVzoOalJOMDTUdbevPowBUNgrbn6BY5hadUymjF1 z2mANvmLwvLK2rJh384ZipY6cX6iq6MzXRBZb5XwPGJuN7oXLa+c+jhO29PqCxaoBsF2 dGrg== 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=Z/HOj+g02ByKe160Z92uXGNhazie9qY974B0HJkNHLc=; b=pprlhrLApdFphEHX9qZ+CRG0Z8H/P0B4VhNJPGzGWr7JUQLaTM4wEqrM3PkZ20fgiF aQJQ/v3D2wMGrHUa5yCVKCUJa6cboglON5c9Pr3FlWplJfdFi++nMg3Ps//FNY4exHpg r3HCQao6J0z/r1MwW9anx2NFPKlme3EWgjNKK8XK5SDd/2fGHtsvL5ga87I20UUxphMV neSDwtaQ77cdJy4cAW0ZPWav3GAGyVUocZViL5aQy2QVO1i6BMnEOLYvtl8PUtxFxWGk QfWfrLnSdPogweCi6a8Gt3FFYZEtSJfe0BPfxQaQ9JkVuJgckuHJ8+JXBx0gqQFlqsV4 sHTw== X-Gm-Message-State: AODbwcAnUqLPfHzkvKYQ+JP3mUP/M/zwglRwCM8Z8+Llv6BSVT6riKE1 YmmNVcK6eDJ2iNpFeytIKLp/ybMS+Wap X-Received: by 10.157.66.10 with SMTP id q10mr3247538ote.2.1496363745368; Thu, 01 Jun 2017 17:35:45 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Peter Thatcher Date: Fri, 02 Jun 2017 00:35:34 +0000 Message-ID: To: Christer Holmberg , "ice@ietf.org" Content-Type: multipart/alternative; boundary="f4030437969c7fc2fe0550ef5542" Archived-At: Subject: Re: [Ice] trickle-11: Unfreezing of candidate pairs on connectivity check success X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2017 00:35:48 -0000 --f4030437969c7fc2fe0550ef5542 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Ah, you are right. That seems wrong to me. But I'd like it if Emil can double check. On Wed, May 31, 2017 at 11:49 PM Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > > I'm a little confused about the second point. It seems like the text i= s > saying to unfreeze the pairs with the same foundation in all check lists, > and that sounds correct to me. > > That is what it should say :) > > But the text says =E2=80=9Cfor the SAME media stream and foundation=E2=80= =9D. It should > say =E2=80=9Cfor ALL media streams with the same foundation=E2=80=9D. > > Also, in Figure 3 only m2 is set to W. m3 and m4 should also be set to W. > > Now, in Figure 4 m3 and m4 ARE set to W, so maybe my issue is that I > don=E2=80=99t really see the difference between Figure 3 and 4. Couldn't = Figure 3 > be removed? > > Regards, > > Christer > > > > > > > > > On Mon, May 29, 2017 at 5:17 AM Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > >> Hi, >> >> We may have discussed this before, but as it still exists in >> draft-trickle-11 I will comment on it: >> >> Section 8.1.1. contains the following text: >> >> "Then, as the checks proceed (see Section 6.2.5.4 of >> [rfc5245bis]), >> for each pair that enters the Succeeded state (denoted here by >> "S"), >> the agent will unfreeze all pairs for the same media stream and >> foundation (e.g., if the pair in column 1, row 1 succeeds then t= he >> agent will unfreeze the pair in column 1, row 2).=C2=B2 >> >> >> First, I believe the 5245bis section to reference is 6.2.5.3.3. >> >> Second, according to the text in section 6.2.5.3.3 of 5245bis, *all* pai= rs >> for *all* streams (for a given foundation) are unfrozen once the checked >> pair succeeds - not only pairs for the same stream. >> >> "The success of the connectivity check might also cause the stat= e >> of >> other candidate pairs to change. The ICE agent MUST set the >> states >> for all other Frozen candidate pairs (in each CHECK LIST in the >> CHECK >> LIST SET) with the same foundation to Waiting." >> >> >> Regards, >> >> Christer >> >> _______________________________________________ >> Ice mailing list >> Ice@ietf.org >> https://www.ietf.org/mailman/listinfo/ice >> > --f4030437969c7fc2fe0550ef5542 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Ah, you are right.=C2=A0 That seems wrong to me. =C2=A0 = =C2=A0But I'd like it if Emil can double check.

On Wed, May 31, 2017 at 11:49 PM Christer Hol= mberg <christer.holmbe= rg@ericsson.com> wrote:
Hi,

> I'm a little confused about the second point.=C2= =A0 It seems like the text is saying to unfreeze the pairs with the same fo= undation in all check lists, and that sounds correct to me.=C2=A0

That is what it should say :)

But the text says =E2=80=9Cfor the SAME media stream and foundation=E2= =80=9D. It should say =E2=80=9Cfor ALL media streams with the same foundati= on=E2=80=9D.

Also, in Figure 3 only m2 is set to W. m3 and m4 should also be set to= W.

Now, in Figure 4 m3 and m4 ARE= =C2=A0set to W, so maybe my issue is that I don=E2=80=99t really see the di= fference between Figure 3 and 4. Couldn't Figure 3 be removed?

Regards,

Christer








On Mon, May 29, 2017 at 5:17 AM Christer Holmberg <christer.ho= lmberg@ericsson.com> wrote:
Hi,

We may have discussed this before, but as it still exists in
draft-trickle-11 I will comment on it:

Section 8.1.1. contains the following text:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 "Then, as the checks proceed (see Section = 6.2.5.4 of [rfc5245bis]),
=C2=A0 =C2=A0 =C2=A0 =C2=A0 for each pair that enters the Succeeded state (= denoted here by "S"),
=C2=A0 =C2=A0 =C2=A0 =C2=A0 the agent will unfreeze all pairs for the same = media stream and
=C2=A0 =C2=A0 =C2=A0 =C2=A0 foundation (e.g., if the pair in column 1, row = 1 succeeds then the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 agent will unfreeze the pair in column 1, row 2= ).=C2=B2


First, I believe the 5245bis section to reference is 6.2.5.3.3.

Second, according to the text in section 6.2.5.3.3 of 5245bis, *all* pairs<= br> for *all* streams (for a given foundation) are unfrozen once the checked pair succeeds - not only pairs for the same stream.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 "The success of the connectivity check mig= ht also cause the state of
=C2=A0 =C2=A0 =C2=A0 =C2=A0 other candidate pairs to change.=C2=A0 The ICE = agent MUST set the states
=C2=A0 =C2=A0 =C2=A0 =C2=A0 for all other Frozen candidate pairs (in each C= HECK LIST in the CHECK
=C2=A0 =C2=A0 =C2=A0 =C2=A0 LIST SET) with the same foundation to Waiting.&= quot;


Regards,

Christer

_______________________________________________
Ice mailing list
Ice@ietf.org
https://www.ietf.org/mailman/listinfo/ice
--f4030437969c7fc2fe0550ef5542-- From nobody Thu Jun 1 23:27:14 2017 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66FBD129B4C for ; Thu, 1 Jun 2017 23:27:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PXLl3l0NnHPP for ; Thu, 1 Jun 2017 23:27:10 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94005124281 for ; Thu, 1 Jun 2017 23:27:10 -0700 (PDT) X-AuditID: c1b4fb3a-6e3519a000004a6a-ab-5931053c8113 Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.183.69]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id D7.88.19050.C3501395; Fri, 2 Jun 2017 08:27:08 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.30]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.03.0339.000; Fri, 2 Jun 2017 08:24:12 +0200 From: Christer Holmberg To: Peter Thatcher , "ice@ietf.org" Thread-Topic: [Ice] Peter's review of ICEbis - Why do we model valid candidate pairs as a separate list of separate candidates from the normal check list? Thread-Index: AQHS2EfLSJWiXi6t0kqXcQwCFgzNt6IPGIOAgACHTICAAP3NgIAAlhAA Date: Fri, 2 Jun 2017 06:24:12 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.4.170508 x-originating-ip: [153.88.183.17] Content-Type: multipart/alternative; boundary="_000_D556DF3D1DAA4christerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprHIsWRmVeSWpSXmKPExsUyM2K7q64Nq2GkwaI55hbfLtRaXFv+mtWB yWPBplKPJUt+MgUwRXHZpKTmZJalFunbJXBlPP6wgK3gkmtF26de5gbGwzZdjJwcEgImErO7 dzB1MXJxCAkcYZR4dXAHG4SziFHiT9Ni9i5GDg42AQuJ7n/aIA0iAh4Sm98sB6sRFpjLKHH9 6x5mEEdEYB6jxO/ls5ghqtwk1n35zgJiswioSLRNvcUKMohXwFqiYaI1xILfjBKbZl9jA6nh FAiUmD1nO5jNKCAm8f3UGiYQm1lAXOLWk/lMEKcKSCzZc54ZwhaVePn4H9hMUQE9iXf7PUFM CQFFieX9chCdCRLrZ71nBbF5BQQlTs58wjKBUWQWkqGzkJTNQlIGETeQeH9uPjOErS2xbOFr KFtfYuOXs4wQtrXEm1lnUdQsYORYxShanFpcnJtuZKSXWpSZXFycn6eXl1qyiREYawe3/Lba wXjwueMhRgEORiUe3tdfDCKFWBPLiitzDzFKcDArifCumw8U4k1JrKxKLcqPLyrNSS0+xCjN waIkzuuw70KEkEB6YklqdmpqQWoRTJaJg1OqgZE9iM/pPVuzy67QCatfpW/sM7wqn3k4bc7P Ywuyt5y7wTltP3fZ81UL7d33zf30zZvlm2mgeYz/EQvVyD93y/9f0g3gFGTSLPwevKny5Zmy mX4X+3zzZTmev43e/nr9pu3phyf6OqnJvFtdyTw9aW/0pTfvWpn6e/3i6r68ueZY6KnFtNp5 2xElluKMREMt5qLiRACEKChrsQIAAA== Archived-At: Subject: Re: [Ice] Peter's review of ICEbis - Why do we model valid candidate pairs as a separate list of separate candidates from the normal check list? X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2017 06:27:12 -0000 --_000_D556DF3D1DAA4christerholmbergericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, >If it's not in any check list, then why not just add it to a check list in= the Succeeded state? I haven=92t studied it in detail, but I GUESS it could be done that way too= . Also, implementers can choose to do it that way. But, repeal of VALID LIST would require quite a bit of work. Also note that= VALID LIST is used in draft-trickle etc, so I wonder whether it=92s worth = the effort=85 Regards, Christer On Wed, May 31, 2017 at 11:20 PM Christer Holmberg > wrote: Hi, I need to take one step back. Keep in mind that pairs in the VALID LIST do not necessarily exist in any C= HECK LIST. See section 6.2.5.3.2. Regards, Christer From: "pthatcher@google.com" > Date: Thursday 1 June 2017 at 04:20 To: Christer Holmberg >, "ice@ietf.org" > Subject: Re: [Ice] Peter's review of ICEbis - Why do we model valid candida= te pairs as a separate list of separate candidates from the normal check li= st? What's the different between "valid" and "succeeded"? On Sun, May 28, 2017 at 11:50 PM Christer Holmberg > wrote: Hi, > - Why do we model valid candidate pairs as a separate list of separate ca= ndidates from the normal check list? > Why not just say that some candidate pairs are valid. Why have this list= of them? Seems like we could remove the concept. This is related to an e-mail I sent some time ago, where I asked whether we= really need all states etc, and even suggested we could remove some of it.= However, I then decided not to do it, because it could end up in a real me= ss. But, related to your question, when I had a look at it I was thinking that = =93VALID=94 could just be a candidate pair state value, rather than a separ= ate list. Regards, Christer --_000_D556DF3D1DAA4christerholmbergericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <39CB062521125043A852B78D56843BD1@ericsson.com> Content-Transfer-Encoding: quoted-printable
Hi,

>If it's not in any check list, then why not just add i= t to a check list in the Succeeded state?  

I haven=92t studied it in detail, but I GUESS it could be done that wa= y too. Also, implementers can choose to do it that way.

But, repeal of VALID LIST would require quite a bit of work. Also note= that VALID LIST is used in draft-trickle etc, so I wonder whether it=92s w= orth the effort=85

Regards,

Christer


On Wed, May 31, 2017 at 11:20 PM Christer Holmberg <christer.holmberg@ericsson.c= om> wrote:
Hi,

I need to take one step back.

Keep in mind that pairs in the VALID LIST do not necessarily exist in = any CHECK LIST.

See section 6.2.5.3.2.

Regards,

Christer

From: "pthatcher@google.com" <pthatcher@google.com>
Date: Thursday 1 June 2017 at 04:20=
To: Christer Holmberg <christer.holmb= erg@ericsson.com>, "ice@ietf.org" <ice@ietf.org>
Subject: Re: [Ice] Peter's review o= f ICEbis - Why do we model valid candidate pairs as a separate list of sepa= rate candidates from the normal check list?

What's the different between "valid" and "s= ucceeded"?  


On Sun, May 28, 2017 at 11:50 PM Christer Holmberg <christer.h= olmberg@ericsson.com> wrote:
Hi,

> - Why do we model valid candidate pairs as a separate list of separate= candidates from the normal check list? 
> Why not just say = that some candidate pairs are valid.  Why have this list of them? &nbs= p;  Seems like we could remove the concept.

This is related to an e-mail I sent some time ago, where I asked wheth= er we really need all states etc, and even suggested we could remove some o= f it. However, I then decided not to do it, because it could end up in a re= al mess.

But, related to your question, when I had a look at it I was thinking = that =93VALID=94 could just be a candidate pair state value, rather than a = separate list.

Regards,

Christer


=
--_000_D556DF3D1DAA4christerholmbergericssoncom_-- From nobody Fri Jun 2 00:00:31 2017 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD2B512E038 for ; Fri, 2 Jun 2017 00:00:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B8w343qLtluA for ; Fri, 2 Jun 2017 00:00:27 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3E6F13146D for ; Fri, 2 Jun 2017 00:00:14 -0700 (PDT) X-AuditID: c1b4fb2d-5a49e9a000000d37-f6-59310cfc1ec5 Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.183.84]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id AB.73.03383.CFC01395; Fri, 2 Jun 2017 09:00:12 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.30]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.03.0339.000; Fri, 2 Jun 2017 08:56:30 +0200 From: Christer Holmberg To: Christer Holmberg , Peter Saint-Andre , Peter Thatcher , =?windows-1254?Q?Ari_Ker=E4nen?= CC: "ice@ietf.org" Thread-Topic: ICE Session definition [was: Trickle ICE review] Thread-Index: AQHS2tWS71IISIKkIkC/8+ijqJUCKKIRN5WA Date: Fri, 2 Jun 2017 06:56:29 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.4.170508 x-originating-ip: [153.88.183.19] Content-Type: text/plain; charset="windows-1254" Content-ID: <09D3B84156835D45879579FF49A225F2@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrOIsWRmVeSWpSXmKPExsUyM2J7iO4fHsNIgxUvzS2+Xai1uLb8NavF sT39zA7MHgs2lXosWfKTyWPunhfMAcxRXDYpqTmZZalF+nYJXBmfFn1mLvjEXfF/3j2mBsYX nF2MnBwSAiYSjYufsHQxcnEICRxhlDj/9QobhLOIUaJj2y32LkYODjYBC4nuf9ogcRGBY4wS H5/NYgOJMwsoSrzcqwYySFjATqJ7zjImEFtEwF7iaXMjO4RtJHFg32Ywm0VAReLSzH8sIDav gLVE47kTzCC2EJB9t2ExWC+ngI3Em6u32EBsRgExie+n1oDFmQXEJW49mc8EcbSAxJI955kh bFGJl4//sYKcIyqgJ/FuvydEWFGi/WkDI0SrgcSRczdZIWxriYbdnSwQtrbEsoWvmSHOEZQ4 OfMJywRG8VlIts1C0j4LSfssJO2zkLQvYGRdxShanFpcnJtuZKyXWpSZXFycn6eXl1qyiREY fQe3/Nbdwbj6teMhRgEORiUe3jdfDCKFWBPLiitzDzFKcDArifC+4TCMFOJNSaysSi3Kjy8q zUktPsQozcGiJM7rsO9ChJBAemJJanZqakFqEUyWiYNTqoFReO8V8zs75F/MTtbfEdaTV6Oi uZ0zNrjM57H8/+23jtYbr3oty5OjufD2m11v7A+KuXBdXD7pzLEbpz739JuwLvxR2bZVbktr CsszzzcP7+h/rXAtvaun2VIU5r5IyPixzvM7L2efFLGLd7ZUem/6JLiF78cT7vVVspq3xL+1 d2cxvZt9zYJbiaU4I9FQi7moOBEAaIPHbboCAAA= Archived-At: Subject: Re: [Ice] ICE Session definition [was: Trickle ICE review] X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2017 07:00:29 -0000 Hi, PR updated, based on comment from Roman. Regards, Christer On 01/06/17 15:49, "Christer Holmberg" wrote: >Hi, > >I=B9ve created a PR, which adds the =B3ICE session=B2 definition to 5245bi= s. > >https://github.com/ice-wg/rfc5245bis/pull/37 > > >Regards, > >Christer > > > >On 30/03/17 20:53, "Ice on behalf of Christer Holmberg" > wrote: > >>Hi, >> >>Perhaps we could say something like "re-start or once all candidates have >>been released", or something like that... We seem to agree, so it's just >>about wording :) >> >>Regards, >> >>Christer >> >>-----Original Message----- >>From: Peter Saint-Andre [mailto:stpeter@stpeter.im] >>Sent: 30 March 2017 20:42 >>To: Peter Thatcher ; Christer Holmberg >>; Ari Ker=E4nen >>Cc: ice@ietf.org >>Subject: Re: [Ice] Trickle ICE review >> >>On 3/30/17 9:45 AM, Peter Thatcher wrote: >>> Ah, I see what you mean now. >>>=20 >>> In that case, could we just define "ICE session" as the something like >>> "stuff until the next ICE restart or the termination of all ICE >>> activity by this agent"? >> >>Right, there's no "ICE session termination" message, so that'll have to >>do. >> >>Peter >> >>_______________________________________________ >>Ice mailing list >>Ice@ietf.org >>https://www.ietf.org/mailman/listinfo/ice > From nobody Fri Jun 2 15:30:25 2017 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 702BE129422 for ; Fri, 2 Jun 2017 15:30:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 tUipd-ZFMnXv for ; Fri, 2 Jun 2017 15:30:23 -0700 (PDT) Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31845129418 for ; Fri, 2 Jun 2017 15:30:23 -0700 (PDT) Received: by mail-oi0-x234.google.com with SMTP id h4so108006236oib.3 for ; Fri, 02 Jun 2017 15:30:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=DVHk3W63l2gKTMnjla4Ab+ahRHERSx6dosrckX4RQ6M=; b=uR/ok0PCYSQiLns9T1/dTbKbTCwr9YDCeHTFzOh9xcyes6McJu7kEKTmB1Bh10Mbw4 zPeSUGNycgIPZz/ZqNT2F/ZHdqYhIVhGATvVVC71w3dYWDLUcTWabZcalIO7rqJsIcaM 4Z1plwEPqlCPnw4LkON00zNYbvOzalms+1d8jJMGpF7yAMzkwUQMV7yL4GHODTix9bDO uvnUxF4JxK0d5FGQbpCDmlJDaaX6Zq3T0ULhMRNEqHPSv/dnr/b6zjchV6aSYBPcTtnP Maoupv27aFXPtMzCmuQjN9lwxN2nFCOHyDC4zsAv1pEGhBgqa86hriwHYcTNG7spJJJR 5slg== 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=DVHk3W63l2gKTMnjla4Ab+ahRHERSx6dosrckX4RQ6M=; b=cK6xRIVvLUVqASvXtJeOeesYGl0WnAIJR7509yvuFJ76bzaTPQ/JET/x2+LbKKGmJR VmZ2vZSv55ZW996OjjLhV83dV9mTtMv3TM0k9JlEerRZe71aK6W19N6hOBNGVUQCmCmm BHoWd4Ct0wzqxSLuCcQITtMsCTPEoPatikfV4dh1rd9+jPwfvnvEV9pHK2OTO235NkcS zX2ykaL3Zi1WHRsyWEfMWTSds2H1njAjnapzQqhT94bnjNN/zFxkGmtQjsnVB2UDA+Ry WMT6lMxvtjDWiDdty70Ix4yXI6DKLiynr2fjkEkzGTaEBKEzzmsd7JDY6TtuOm5GvTVi R6Tw== X-Gm-Message-State: AODbwcBq6+eKo2iWpNvhaGqFlhRhDxxbpD4Xb27njol7VQYbLG+OC8eZ VGxxqm/eZjhjYbPiduqkewHT4K3Z5xot X-Received: by 10.202.85.13 with SMTP id j13mr5415324oib.90.1496442622517; Fri, 02 Jun 2017 15:30:22 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Peter Thatcher Date: Fri, 02 Jun 2017 22:30:11 +0000 Message-ID: To: Christer Holmberg , "ice@ietf.org" Content-Type: multipart/alternative; boundary="001a113d3008f17f00055101b238" Archived-At: Subject: Re: [Ice] Peter's review of ICEbis - Why do we model valid candidate pairs as a separate list of separate candidates from the normal check list? X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2017 22:30:24 -0000 --001a113d3008f17f00055101b238 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Yes, it would be a big change. I'll see if I have some time next week to take a crack at it. On Thu, Jun 1, 2017 at 11:27 PM Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > >If it's not in any check list, then why not just add it to a check list > in the Succeeded state? > > I haven=E2=80=99t studied it in detail, but I GUESS it could be done that= way too. > Also, implementers can choose to do it that way. > > But, repeal of VALID LIST would require quite a bit of work. Also note > that VALID LIST is used in draft-trickle etc, so I wonder whether it=E2= =80=99s > worth the effort=E2=80=A6 > > Regards, > > Christer > > > On Wed, May 31, 2017 at 11:20 PM Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > >> Hi, >> >> I need to take one step back. >> >> Keep in mind that pairs in the VALID LIST do not necessarily exist in an= y >> CHECK LIST. >> >> See section 6.2.5.3.2. >> >> Regards, >> >> Christer >> >> From: "pthatcher@google.com" >> Date: Thursday 1 June 2017 at 04:20 >> To: Christer Holmberg , "ice@ietf.org" < >> ice@ietf.org> >> Subject: Re: [Ice] Peter's review of ICEbis - Why do we model valid >> candidate pairs as a separate list of separate candidates from the norma= l >> check list? >> >> What's the different between "valid" and "succeeded"? >> >> >> On Sun, May 28, 2017 at 11:50 PM Christer Holmberg < >> christer.holmberg@ericsson.com> wrote: >> >>> Hi, >>> >>> > - Why do we model valid candidate pairs as a separate list of separat= e >>> candidates from the normal check list? >>> > Why not just say that some candidate pairs are valid. Why have this >>> list of them? Seems like we could remove the concept. >>> >>> This is related to an e-mail I sent some time ago, where I asked whethe= r >>> we really need all states etc, and even suggested we could remove some = of >>> it. However, I then decided not to do it, because it could end up in a = real >>> mess. >>> >>> But, related to your question, when I had a look at it I was thinking >>> that =E2=80=9CVALID=E2=80=9D could just be a candidate pair state value= , rather than a >>> separate list. >>> >>> Regards, >>> >>> Christer >>> >>> >>> >>> --001a113d3008f17f00055101b238 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Yes, it would be a big change.=C2=A0 I'll see if I hav= e some time next week to take a crack at it.

On Thu, Jun 1, 2017 at 11:27 PM Christer Holmberg &l= t;christer.holmberg@erics= son.com> wrote:
Hi,

>If it's not in any check list, then why not just a= dd it to a check list in the Succeeded state? =C2=A0

I haven=E2=80=99t studied it in detail, = but I GUESS it could be done that way too. Also, implementers can choose to= do it that way.

But, repeal of VALID LIST would require quite a bit of work. Also note= that VALID LIST is used in draft-trickle etc, so I wonder whether it=E2=80= =99s worth the effort=E2=80=A6

Regards,

Christer


On Wed, May 31, 2017 at 11:20 PM Christer Holmberg <christer.h= olmberg@ericsson.com> wrote:
Hi,

I need to take one step back.

Keep in mind that pairs in the VALID LIST do not necessarily exist in = any CHECK LIST.

See section=C2=A06.2.5.3.2.

Regards,

Christer

From: "pthatcher@google.com" <pthatcher@google.com>
Date: Thursday 1 June 2017 at 04:20=
To: Christer Holmberg <christer.holmb= erg@ericsson.com>, "ice@ietf.org" <ice@ietf.org>
Subject: Re: [Ice] Peter's revi= ew of ICEbis - Why do we model valid candidate pairs as a separate list of = separate candidates from the normal check list?

What's the different between "valid" and &qu= ot;succeeded"? =C2=A0


On Sun, May 28, 2017 at 11:50 PM Christer Holmberg <christer.h= olmberg@ericsson.com> wrote:
Hi,

> - Why do we model valid candidate pairs as a separate list of separate= candidates from the normal check list?=C2=A0
>=C2=A0Why not just say = that some candidate pairs are valid.=C2=A0 Why have this list of them? =C2= =A0 =C2=A0Seems like we could remove the concept.

This is related to an e-mail I sent some time ago, where I asked wheth= er we really need all states etc, and even suggested we could remove some o= f it. However, I then decided not to do it, because it could end up in a re= al mess.

But, related to your question, when I had a look at it I was thinking = that =E2=80=9CVALID=E2=80=9D could just be a candidate pair state value, ra= ther than a separate list.

Regards,

Christer
--001a113d3008f17f00055101b238-- From nobody Mon Jun 5 00:47:44 2017 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94F77129B9B for ; Mon, 5 Jun 2017 00:47:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, 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 m_tE6gzgDPYg for ; Mon, 5 Jun 2017 00:47:41 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22975129B8D for ; Mon, 5 Jun 2017 00:47:40 -0700 (PDT) X-AuditID: c1b4fb25-73a9f9a0000055fe-84-59350c9b6a8d Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.183.90]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 74.31.22014.B9C05395; Mon, 5 Jun 2017 09:47:39 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.30]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.03.0339.000; Mon, 5 Jun 2017 09:45:55 +0200 From: Christer Holmberg To: Peter Thatcher , "ice@ietf.org" Thread-Topic: [Ice] Peter's review of ICEbis - Why do we model valid candidate pairs as a separate list of separate candidates from the normal check list? Thread-Index: AQHS2EfLSJWiXi6t0kqXcQwCFgzNt6IPGIOAgACHTICAAP3NgIAAlhAAgADZ1ICAA/QFAA== Date: Mon, 5 Jun 2017 07:45:54 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.4.170508 x-originating-ip: [153.88.183.146] Content-Type: multipart/alternative; boundary="_000_D55AE7761DBD4christerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprHIsWRmVeSWpSXmKPExsUyM2J7lO5sHtNIgx3LZS2+Xai1uLb8NasD k8eCTaUeS5b8ZApgiuKySUnNySxLLdK3S+DKuDr7AXvBveiKbWtLGxin+HcxcnJICJhInJq1 mxXEFhI4wihxq8++i5ELyF7EKNH6bzlbFyMHB5uAhUT3P22QGhEBD4nNb0DCXBzCAnMZJa5/ 3cMM4ogIzGOU+L18FjNEVZjE0d8bwGwWARWJ2VOXgW3gFbCW2LjjFSPEhi9MEnu//GYBSXAK BEq823scrIhRQEzi+6k1TCA2s4C4xK0n85kgThWQWLLnPDOELSrx8vE/VpDrRAX0JN7t94QI K0n82HCJBaI1QeLP7cPsEHsFJU7OfMIygVFkFpKps5CUzUJSBhE3kHh/bj4zhK0tsWzhayhb X2Ljl7OMELa1xLZNl9iQ1Sxg5FjFKFqcWpyUm25krJdalJlcXJyfp5eXWrKJERhrB7f8Vt3B ePmN4yFGAQ5GJR7eLRymkUKsiWXFlbmHGCU4mJVEeIuvm0QK8aYkVlalFuXHF5XmpBYfYpTm YFES53XcdyFCSCA9sSQ1OzW1ILUIJsvEwSnVwBjOKpCVvo59cs+OBfMPSjtZqiaUnvM6ly4b 2PHozfzDv/iXTA+33bPL/qnPvQWLRDnVVryrEjrNw6D8u62nItw97ib/vhu5U72qTGuZPnGy 9EyZJbdm/4lLL/l2fjyWd/TjaabYk67tmeXe5Xtf+3JM1FBcu3i1ktWJJOl1BUur3lk7PDr2 tVOJpTgj0VCLuag4EQAN2ubUsQIAAA== Archived-At: Subject: Re: [Ice] Peter's review of ICEbis - Why do we model valid candidate pairs as a separate list of separate candidates from the normal check list? X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2017 07:47:42 -0000 --_000_D55AE7761DBD4christerholmbergericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, >Yes, it would be a big change. I'll see if I have some time next week to = take a crack at it. You can of course always write a PR, but in order not to waste your time I = think the community should first decide on whether we want to do such chang= e. Also, as your suggestion means that SUCCEEDED means valid, it also removes = the current requirement that you need to have SUCCEEDED pairs for EACH comp= onent of a stream in order for a pair to be valid. I know there is a separa= te suggestion to remove the component concept, and consider everything sepa= rate streams, so we really need to consider how far we want to go. Regards, Christer On Thu, Jun 1, 2017 at 11:27 PM Christer Holmberg > wrote: Hi, >If it's not in any check list, then why not just add it to a check list in= the Succeeded state? I haven=92t studied it in detail, but I GUESS it could be done that way too= . Also, implementers can choose to do it that way. But, repeal of VALID LIST would require quite a bit of work. Also note that= VALID LIST is used in draft-trickle etc, so I wonder whether it=92s worth = the effort=85 Regards, Christer On Wed, May 31, 2017 at 11:20 PM Christer Holmberg > wrote: Hi, I need to take one step back. Keep in mind that pairs in the VALID LIST do not necessarily exist in any C= HECK LIST. See section 6.2.5.3.2. Regards, Christer From: "pthatcher@google.com" > Date: Thursday 1 June 2017 at 04:20 To: Christer Holmberg >, "ice@ietf.org" > Subject: Re: [Ice] Peter's review of ICEbis - Why do we model valid candida= te pairs as a separate list of separate candidates from the normal check li= st? What's the different between "valid" and "succeeded"? On Sun, May 28, 2017 at 11:50 PM Christer Holmberg > wrote: Hi, > - Why do we model valid candidate pairs as a separate list of separate ca= ndidates from the normal check list? > Why not just say that some candidate pairs are valid. Why have this list= of them? Seems like we could remove the concept. This is related to an e-mail I sent some time ago, where I asked whether we= really need all states etc, and even suggested we could remove some of it.= However, I then decided not to do it, because it could end up in a real me= ss. But, related to your question, when I had a look at it I was thinking that = =93VALID=94 could just be a candidate pair state value, rather than a separ= ate list. Regards, Christer --_000_D55AE7761DBD4christerholmbergericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <0E6ACC28BBDF024B981AE3407D624731@ericsson.com> Content-Transfer-Encoding: quoted-printable
Hi,

>Yes, it would be a big change.  I'll see if I hav= e some time next week to take a crack at it.

You can of course always write a PR, but in order not to waste your ti= me I think the community should first decide on whether we want to do such = change.

Also, as your suggestion means that SUCCEEDED means valid, it also rem= oves the current requirement that you need to have SUCCEEDED pairs for EACH= component of a stream in order for a pair to be valid. I know there is a s= eparate suggestion to remove the component concept, and consider everything separate streams, so we really = need to consider how far we want to go.

Regards,

Christer



On Thu, Jun 1, 2017 at 11:27 PM Christer Holmberg <christer.holmberg@ericsson.co= m> wrote:
Hi,

>If it's not in any check list, then why not just add i= t to a check list in the Succeeded state?  

I haven=92t studied it in detail, but I GUESS it could be done that wa= y too. Also, implementers can choose to do it that way.

But, repeal of VALID LIST would require quite a bit of work. Also note= that VALID LIST is used in draft-trickle etc, so I wonder whether it=92s w= orth the effort=85

Regards,

Christer


On Wed, May 31, 2017 at 11:20 PM Christer Holmberg <christer.h= olmberg@ericsson.com> wrote:
Hi,

I need to take one step back.

Keep in mind that pairs in the VALID LIST do not necessarily exist in = any CHECK LIST.

See section 6.2.5.3.2.

Regards,

Christer

From: "pthatcher@google.com" <pthatcher@google.com>
Date: Thursday 1 June 2017 at 04:20=
To: Christer Holmberg <christer.holmb= erg@ericsson.com>, "ice@ietf.org" <ice@ietf.org>
Subject: Re: [Ice] Peter's review o= f ICEbis - Why do we model valid candidate pairs as a separate list of sepa= rate candidates from the normal check list?

What's the different between "valid" and "s= ucceeded"?  


On Sun, May 28, 2017 at 11:50 PM Christer Holmberg <christer.h= olmberg@ericsson.com> wrote:
Hi,

> - Why do we model valid candidate pairs as a separate list of separate= candidates from the normal check list? 
> Why not just say = that some candidate pairs are valid.  Why have this list of them? &nbs= p;  Seems like we could remove the concept.

This is related to an e-mail I sent some time ago, where I asked wheth= er we really need all states etc, and even suggested we could remove some o= f it. However, I then decided not to do it, because it could end up in a re= al mess.

But, related to your question, when I had a look at it I was thinking = that =93VALID=94 could just be a candidate pair state value, rather than a = separate list.

Regards,

Christer



 --_000_D55AE7761DBD4christerholmbergericssoncom_-- From nobody Mon Jun 5 01:30:18 2017 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FD4512E91F for ; Mon, 5 Jun 2017 01:30:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YemSHkxn36Ec for ; Mon, 5 Jun 2017 01:30:16 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFC16126DC2 for ; Mon, 5 Jun 2017 01:30:15 -0700 (PDT) X-AuditID: c1b4fb2d-5a49e9a000000d37-ee-593516969f43 Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.183.36]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id AD.70.03383.69615395; Mon, 5 Jun 2017 10:30:14 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.30]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.03.0339.000; Mon, 5 Jun 2017 10:28:19 +0200 From: Christer Holmberg To: "ice@ietf.org" Thread-Topic: trickle-ice-11: Comment on section 1 (Introduction) Thread-Index: AQHS3dWubU9mGmg3tkGQmXXkN0+nMw== Date: Mon, 5 Jun 2017 08:28:18 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.4.170508 x-originating-ip: [153.88.183.20] Content-Type: multipart/alternative; boundary="_000_D55AF2551DC13christerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrNLMWRmVeSWpSXmKPExsUyM2K7iu40MdNIg1WzxSy+Xah1YPRYsuQn UwBjFJdNSmpOZllqkb5dAlfG6y+iBe1iFSs3PGdqYNwj1MXIySEhYCJx/8V55i5GLg4hgSOM EvuOz4ZyFjFKXDi/lLGLkYODTcBCovufNkiDiICixMyWZ8wgtrCArcTn8+eZIeJOEv9nL2eE sPUkulduYQWxWQRUJP4suwUW5xWwluj81gYWZxQQk/h+ag0TiM0sIC5x68l8JoiDBCSW7IGY KSEgKvHy8T9WkBNEgWa+2+8JEVaUuDp9OVRrgkR/70pmiPGCEidnPmGZwCg0C8nUWUjKZiEp g4gbSLw/N58ZwtaWWLbwNZStL7Hxy1lGCNtaonXzFUZkNQsYOVYxihanFhfnphsZ66UWZSYX F+fn6eWllmxiBEbJwS2/dXcwrn7teIhRgINRiYf3P5tppBBrYllxZe4hRgkOZiUR3uLrJpFC vCmJlVWpRfnxRaU5qcWHGKU5WJTEeR32XYgQEkhPLEnNTk0tSC2CyTJxcEo1MPpUz7k9KclS LO/O4al2Ww4vWX4w2/zk7+OrTdu4v+x93SQdN8NO+Fwiu9LMs/4yIjrlyXUHliT/tTn1+5eZ QeqrA4+vq6S/KznbFXHOz3TC9vIYb+OE7O4m6ensu30PntVN2VHUfv+F4iyrD3e707N/RwhE FShqb37fJsTIf+5VtnQsl/m5eCWW4oxEQy3mouJEAI63/8+OAgAA Archived-At: Subject: [Ice] trickle-ice-11: Comment on section 1 (Introduction) X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2017 08:30:17 -0000 --_000_D55AF2551DC13christerholmbergericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, Section 1 (Introduction): The text says: "This document defines an alternative or supplementary mode of operation for ICE implementations, known as "Trickle ICE", in which candidates can be exchanged incrementally. This enables ICE agents to exchange candidates as soon as an ICE session has been initiated." - =93alternative or supplementary=94 sounds strange. I think we can remove = that, and simply say =93an operation for ICE implementations,=85=94 - I suggest to enhance the second sentence by saying =93=85as soon as an IC= E session has been initiated an a candidate becomes available.=94 - For =93ICE session=94, please add a reference to draft-5245bis. The defin= ition for ICE session will show up there in the next version of the draft (= PR exists)=85 :) Regards, Christer --_000_D55AF2551DC13christerholmbergericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <3FF2811DCDC43C458324F8197664B146@ericsson.com> Content-Transfer-Encoding: quoted-printable

Hi,

Section 1 (Introduction):

The text says:
   "This document defines an =
alternative or supplementary mode of
   operation for ICE implementations, known as "Trickle ICE", in =
which
   candidates can be exchanged incrementally.  This enables ICE agents
   to exchange candidates as soon as an ICE session has been initiated.&quo=
t;
- =93alternative or supplementary=94 sounds strange. I think we can re= move that, and simply say =93an operation for ICE implementations,=85=94

- I suggest to enhance the second sentence by saying =93=85as soon as = an ICE session has been initiated an a candidate becomes available.=94

- For =93ICE session=94, please add a reference to draft-5245bis. The = definition for ICE session will show up there in the next version of the dr= aft (PR exists)=85 :)

Regards,

Christer
  
--_000_D55AF2551DC13christerholmbergericssoncom_-- From nobody Mon Jun 5 01:31:36 2017 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CED7D12E91F for ; Mon, 5 Jun 2017 01:31:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SGJ_D9lO3VhB for ; Mon, 5 Jun 2017 01:31:33 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A439126DC2 for ; Mon, 5 Jun 2017 01:31:33 -0700 (PDT) X-AuditID: c1b4fb3a-6e3519a000004a6a-c6-593516e3b4eb Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.183.66]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 27.E3.19050.3E615395; Mon, 5 Jun 2017 10:31:31 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.30]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.03.0339.000; Mon, 5 Jun 2017 10:30:58 +0200 From: Christer Holmberg To: "ice@ietf.org" Thread-Topic: draft-trickle-11: Comment on section 5 Thread-Index: AQHS3dYNK0RRXLHo9UKFMfGFoXKmew== Date: Mon, 5 Jun 2017 08:30:57 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.4.170508 x-originating-ip: [153.88.183.20] Content-Type: multipart/alternative; boundary="_000_D55AF2F41DC1Echristerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrDLMWRmVeSWpSXmKPExsUyM2K7k+5jMdNIgwuNlhbfLtQ6MHosWfKT KYAxissmJTUnsyy1SN8ugSvj7pW57AXveSoOzrvM2MDYxt3FyMkhIWAicaHpP2sXIxeHkMAR RokNK99AOYsYJdZv+QPkcHCwCVhIdP/TBmkQEVCUmNnyjBnEFhbQl3h7/BALRNxE4v+Vk2wQ tp7Ege8djCA2i4CKxMvmY2BxXgFriam//zCB2IwCYhLfT60Bs5kFxCVuPZnPBHGQgMSSPeeZ IWxRiZeP/4GdIAo0891+T4iwosTV6cuhWhMk7k98xAgxXlDi5MwnLBMYhWYhmToLSdksJGUQ cQOJ9+fmM0PY2hLLFr6GsvUlNn45ywhhW0vs7PzGgqxmASPHKkbR4tTi4tx0IyO91KLM5OLi /Dy9vNSSTYzAODm45bfVDsaDzx0PMQpwMCrx8P5iM40UYk0sK67MPcQowcGsJMJbfN0kUog3 JbGyKrUoP76oNCe1+BCjNAeLkjivw74LEUIC6YklqdmpqQWpRTBZJg5OqQbGpS6RMr/LflYW aYTqcyb12p1TecnWKffXtcS8IXrma9uWmfoHmx7wnLhbyR8aJWD+PCYw+ufWR7OfFJxy0LDe z/AxSsdE5/hNCaMrh6bk2GRd/X8py4phC/e14Koilu1PrnZJLc4wXHJX4sz5luyu0D9FPR2l dy77rLr6Yr8Ea/3u7Z6BMo5KLMUZiYZazEXFiQANa3hIjwIAAA== Archived-At: Subject: [Ice] draft-trickle-11: Comment on section 5 X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2017 08:31:35 -0000 --_000_D55AF2F41DC1Echristerholmbergericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Section 5 The text says: "If support for Trickle ICE is confirmed, an agent will automatically assume support for regular ICE as well even if the support verification procedure in [rfc5245bis] indicates otherwise." What =93support verification procedure=94 are you referring to? Regards, Christer --_000_D55AF2F41DC1Echristerholmbergericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <5337FD49B094D844A1D2007BAA61F84E@ericsson.com> Content-Transfer-Encoding: quoted-printable
Section 5

The text says:
   "If support for Trickle IC=
E is confirmed, an agent will automatically
   assume support for regular ICE as well even if the support
   verification procedure in [rfc5245bis] indicates otherwise."
What =93support verification procedure=94 are you referring to?

Regards,

Christer
--_000_D55AF2F41DC1Echristerholmbergericssoncom_-- From nobody Mon Jun 5 01:32:36 2017 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F40A12EA54 for ; Mon, 5 Jun 2017 01:32:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R_3zVPfWqD7T for ; Mon, 5 Jun 2017 01:32:32 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B880712E91F for ; Mon, 5 Jun 2017 01:32:31 -0700 (PDT) X-AuditID: c1b4fb25-73a9f9a0000055fe-39-5935171d4644 Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.183.51]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id FA.BD.22014.D1715395; Mon, 5 Jun 2017 10:32:30 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.30]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.03.0339.000; Mon, 5 Jun 2017 10:29:26 +0200 From: Christer Holmberg To: "ice@ietf.org" Thread-Topic: draft-trickle-11: Comment on section 2 (Terminology) Thread-Index: AQHS3dXXyrRWfecGrESOQzY6tdFuig== Date: Mon, 5 Jun 2017 08:29:26 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.4.170508 x-originating-ip: [153.88.183.20] Content-Type: multipart/alternative; boundary="_000_D55AF2991DC18christerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrNLMWRmVeSWpSXmKPExsUyM2K7sa6cuGmkweYtPBbfLtQ6MHosWfKT KYAxissmJTUnsyy1SN8ugStjzzeJgmbJivMXLrM1MPaKdjFyckgImEhsO3+QpYuRi0NI4Aij xIEN51khnEWMEq/+fWPvYuTgYBOwkOj+pw3SICKgKDGz5RkziC0sYCvxYcsRNoi4k8TEpTvY IWw9idvt68FsFgEViXdHd4DV8ApYS1w+MoURxGYUEJP4fmoNE4jNLCAucevJfCaIgwQkluw5 zwxhi0q8fPyPFeQEUaCZ7/Z7QoQVJa5OXw7VmiCx5fYGqPGCEidnPmGZwCg0C8nUWUjKZiEp g4gbSLw/N58ZwtaWWLbwNZStL7Hxy1lGCNta4sWee2zIahYwcqxiFC1OLU7KTTcy1kstykwu Ls7P08tLLdnECIySg1t+q+5gvPzG8RCjAAejEg/vFg7TSCHWxLLiytxDjBIczEoivMXXTSKF eFMSK6tSi/Lji0pzUosPMUpzsCiJ8zruuxAhJJCeWJKanZpakFoEk2Xi4JRqYNQpvdJr6aTP nd7FLNy8L5NdgO/RGrGNG33O7GjcbxPu5nb/X4abYdzZR3dOSSYq3rmwR8PVWuBXsO9Fn2vt HpE6VzP9yuRS2PnVgy/dmq1z2y6dbymjs/B/9QWJajLL9lS58cZ+9f+gv4DF4MKL2UY33918 E/S/6VCU54H318xNnWZ8aAmPUmIpzkg01GIuKk4EANrqlR6OAgAA Archived-At: Subject: [Ice] draft-trickle-11: Comment on section 2 (Terminology) X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2017 08:32:34 -0000 --_000_D55AF2991DC18christerholmbergericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Section 2 (Terminology) There is a definition for =93candidate gatherer=94. Do we really need that?= There is no such thing in 5245bis, and I fail to see why trickle would nee= d it. I don=92t think the =93ICE parameter=94 definition is aligned with 5245bis.= 5245bis doesn=92t seem to have a clear definition of =93ICE parameter=94 (= perhaps we should fix that), but it doesn=92t seem to exclude candidate spe= cific parameters. Also, in the definition for =93Full Trickle=94 it seems to indicate that IC= E parameters can carry candidates. Also later in the document there is text= about using ICE parameters to carry candidates. I think using =93ICE parameters=94 in these definitions is confusing. Shoul= dn=92t we talk about candidates that are individually exchanged at some poi= nt, once the ICE session has been initiated, before the nomination? Regards, Christer --_000_D55AF2991DC18christerholmbergericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <2919ED291592AC4A832EAD1D55056DEE@ericsson.com> Content-Transfer-Encoding: quoted-printable

Section 2 (Terminology)

There is a definition for =93candidate gatherer=94. Do we really need = that? There is no such thing in 5245bis, and I fail to see why trickle woul= d need it.

I don=92t think the =93ICE parameter=94 definition is aligned with 524= 5bis. 5245bis doesn=92t seem to have a clear definition of =93ICE parameter= =94 (perhaps we should fix that), but it doesn=92t seem to exclude candidat= e specific parameters. 

Also, in the definition for =93Full Trickle=94 it seems to indicate th= at ICE parameters can carry candidates. Also later in the document there is= text about using ICE parameters to carry candidates.       =                      = ;                     &nb= sp;                             &nbs= p;                     &n= bsp;      

I think using =93ICE parameters=94 in these definitions is confusing. = Shouldn=92t we talk about candidates that are individually exchanged at&nbs= p;some point, once the ICE sessio= n has been initiated, before the nomination?

Regards,

Christer
--_000_D55AF2991DC18christerholmbergericssoncom_-- From nobody Mon Jun 5 01:33:58 2017 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E39212EA67 for ; Mon, 5 Jun 2017 01:33:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B-2HFwpyROuo for ; Mon, 5 Jun 2017 01:33:56 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D135712EA5A for ; Mon, 5 Jun 2017 01:33:55 -0700 (PDT) X-AuditID: c1b4fb25-73a9f9a0000055fe-a1-5935177263a7 Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.183.27]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id BA.3E.22014.27715395; Mon, 5 Jun 2017 10:33:54 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.30]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.03.0339.000; Mon, 5 Jun 2017 10:30:17 +0200 From: Christer Holmberg To: "ice@ietf.org" Thread-Topic: draft-trickle-11: Comment on section 3 Thread-Index: AQHS3dX2vHJOf6oHg0GY4LkU+XNtog== Date: Mon, 5 Jun 2017 08:30:17 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.4.170508 x-originating-ip: [153.88.183.146] Content-Type: multipart/alternative; boundary="_000_D55AF2CC1DC1Bchristerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrFLMWRmVeSWpSXmKPExsUyM2K7tG6RuGmkwf2PQhbfLtQ6MHosWfKT KYAxissmJTUnsyy1SN8ugSvj2qllTAX3+Cpa3zxgb2DczdPFyMkhIWAisfXierYuRi4OIYEj jBLb9vaygiSEBBYxSny7x9XFyMHBJmAh0f1PGyQsIqAoMbPlGTOILSygL/F4wmQWiLiJxNuj d9kgbD2Jy/ves4G0sgioSPzblAgS5hWwlvjfvo8dxGYUEJP4fmoNE4jNLCAucevJfCaIcwQk luw5zwxhi0q8fPyPFWSMKNDId/s9IcJKEj82XGKBaE2QWP96PTPEeEGJkzOfsExgFJqFZOos JGWzkJRBxA0k3p+bzwxha0ssW/gaytaX2PjlLCOEbS2xccdpJmQ1Cxg5VjGKFqcWJ+WmGxnr pRZlJhcX5+fp5aWWbGIExsjBLb9VdzBefuN4iFGAg1GJh3cLh2mkEGtiWXFl7iFGCQ5mJRHe 4usmkUK8KYmVValF+fFFpTmpxYcYpTlYlMR5HfddiBASSE8sSc1OTS1ILYLJMnFwSjUwTrp2 MzA5l2P5BuMLGRUWj3M3twkbZr1++1cvWknG1ELo6Fz+omv3vyV8S58VL7TtfPX9zSZTXd/f nMLXcdLgsIPWDn4z05WptV47PW/r152T+rvVwMPeQKF+UrNDTiRLf1OCT4jo1MYYl7pnaxsK NkTpCadGSp+Wf2aQsk/54SrLSeWiwseVWIozEg21mIuKEwFyfjc5jQIAAA== Archived-At: Subject: [Ice] draft-trickle-11: Comment on section 3 X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2017 08:33:57 -0000 --_000_D55AF2CC1DC1Bchristerholmbergericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Section 3 The text says: "If an agent determines that the remote party does not support Trickle I= CE, it MUST fall back to using regular ICE or abandon the entire session." This is confusing, because earlier the draft says that half trickle can be = used if the remote party doesn=92t support trickle. And, I don=92t think = =93regular ICE=94 and =93half trickle=94 are the same things, are they? Regards, Christer --_000_D55AF2CC1DC1Bchristerholmbergericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <72E61A5BC937684AB935435F3E880C3F@ericsson.com> Content-Transfer-Encoding: quoted-printable
Section 3

The text says:
   "If an agent determines th=
at the remote party does not support Trickle ICE, it
   MUST fall back to using regular ICE or abandon the entire session."=
This is confusing, because earlier the draft says that half trickle ca= n be used if the remote party doesn=92t support trickle. And, I don=92t thi= nk =93regular ICE=94 and =93half trickle=94 are the same things, are they?<= /div>

Regards,

Christer
--_000_D55AF2CC1DC1Bchristerholmbergericssoncom_-- From nobody Mon Jun 5 01:35:08 2017 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 326EB12EA6A for ; Mon, 5 Jun 2017 01:35:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A2T-SvoeSj2F for ; Mon, 5 Jun 2017 01:35:05 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F86912EA5A for ; Mon, 5 Jun 2017 01:35:05 -0700 (PDT) X-AuditID: c1b4fb3a-6e3519a000004a6a-6a-593517b79680 Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.183.75]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 28.F4.19050.7B715395; Mon, 5 Jun 2017 10:35:03 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.30]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.03.0339.000; Mon, 5 Jun 2017 10:31:54 +0200 From: Christer Holmberg To: "ice@ietf.org" Thread-Topic: draft-trickle-11: Comment on sections 5 & 6 Thread-Index: AQHS3dYvAA2KAaqhzk+dsIvRsQ6RRw== Date: Mon, 5 Jun 2017 08:31:54 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.4.170508 x-originating-ip: [153.88.183.146] Content-Type: multipart/alternative; boundary="_000_D55AF32D1DC21christerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrNLMWRmVeSWpSXmKPExsUyM2K7t+52cdNIg9ZV1hbfLtQ6MHosWfKT KYAxissmJTUnsyy1SN8ugSvjxsdz7AXn+CpWtp1gaWA8wtPFyMkhIWAi8XnZBOYuRi4OIYEj jBKnHk1ih3AWMUr8/fYDKMPBwSZgIdH9TxukQURAUWJmyzNmEFsYqPnWqk9gJSIClhJPt1lD lOhJfP96hx3EZhFQkbh54iILiM0rYC3xd9MXNhCbUUBM4vupNUwgNrOAuMStJ/OZIO4RkFiy 5zwzhC0q8fLxP1aQ8aJAM9/t94QIK0n82HCJBaI1QWLptuesEOMFJU7OfMIygVFoFpKps5CU zUJSBhE3kHh/bj4zhK0tsWzhayhbX2Ljl7OMELa1xJa7Z1DULGDkWMUoWpxaXJybbmSkl1qU mVxcnJ+nl5dasokRGCUHt/y22sF48LnjIUYBDkYlHt5fbKaRQqyJZcWVuYcYJTiYlUR4i6+b RArxpiRWVqUW5ccXleakFh9ilOZgURLnddh3IUJIID2xJDU7NbUgtQgmy8TBKdXA2Pd9YcR3 zqiZLpk59XsKLrsc5Cs0fMr7vN1M9XjQ8ok1KQ0X3s59e8A0bfed8qgLziefuny7YvZpJ2uJ dwtjCd+P/HvnyjrDDoR01i2/VqxmbGps/mD34dWLDR3OtCxn/5gfvNr2ie3x890SZXdvHNsR 8jdw71anoh8uBpFH15uaO9+b7vLeUImlOCPRUIu5qDgRAEytVNmOAgAA Archived-At: Subject: [Ice] draft-trickle-11: Comment on sections 5 & 6 X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2017 08:35:07 -0000 --_000_D55AF32D1DC21christerholmbergericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Section 5 & 6 I suggest the main chapter names to be =93Responder Procedures=94 and =93In= itiator Procedures=94, and then place the sub sections below those. The text mixes between =93responder=94 and =93agent=94 terminology. I unde= rstand that =93agent=94 can be used when describing something that applies = to both =93responder=94 and =93initiator=94, but the text seems to use =93a= gent=94 even when only talking about the responder. Regards, Christer --_000_D55AF32D1DC21christerholmbergericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <8BDEAD8BD0242445AEC74B30B0B2177D@ericsson.com> Content-Transfer-Encoding: quoted-printable
Section 5 & 6

I suggest the main chapter names to be =93Responder Procedures=94 and = =93Initiator Procedures=94, and then place the sub sections below those.

The text mixes between =93responder=94 and =93agent=94 terminology. &n= bsp;I understand that =93agent=94 can be used when describing something tha= t applies to both =93responder=94 and =93initiator=94, but the text seems t= o use =93agent=94 even when only talking about the responder.

Regards,

Christer
--_000_D55AF32D1DC21christerholmbergericssoncom_-- From nobody Mon Jun 5 01:35:31 2017 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6AEF127137 for ; Mon, 5 Jun 2017 01:35:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6O1SE3dF1dQz for ; Mon, 5 Jun 2017 01:35:29 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF63C12EA5A for ; Mon, 5 Jun 2017 01:35:28 -0700 (PDT) X-AuditID: c1b4fb2d-5a49e9a000000d37-b0-593517cfe128 Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.183.21]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 9B.E1.03383.FC715395; Mon, 5 Jun 2017 10:35:27 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.30]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.03.0339.000; Mon, 5 Jun 2017 10:34:07 +0200 From: Christer Holmberg To: "ice@ietf.org" Thread-Topic: draft-trickle-11: Comment on section 15 Thread-Index: AQHS3dZ/cBKgt2WVVE+FUUPx8uxmVw== Date: Mon, 5 Jun 2017 08:34:07 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.4.170508 x-originating-ip: [153.88.183.20] Content-Type: multipart/alternative; boundary="_000_D55AF3B21DC27christerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrDLMWRmVeSWpSXmKPExsUyM2K7qO55cdNIg+YWIYtvF2odGD2WLPnJ FMAYxWWTkpqTWZZapG+XwJVx/uBe1oLtghW71m9jbWC8wdfFyMkhIWAisebHfMYuRi4OIYEj jBJbp8+GchYxSqya95yti5GDg03AQqL7nzZIg4iAosTMlmfMILawgIHE1Z5LrBBxU4m+yRsY IWw9iSnbvoPVsAioSCxt3MwGYvMKWEu0TO4HsxkFxCS+n1rDBGIzC4hL3HoynwniIAGJJXvO M0PYohIvH/9jBTlBFGjmu/2eEGFFiavTl0O1JkhsuHaIHWK8oMTJmU9YJjAKzUIydRaSsllI yiDiBhLvz81nhrC1JZYtfA1l60ts/HKWEcK2lrhy5RUbspoFjByrGEWLU4uLc9ONjPVSizKT i4vz8/TyUks2MQLj5OCW37o7GFe/djzEKMDBqMTD+5/NNFKINbGsuDL3EKMEB7OSCG/xdZNI Id6UxMqq1KL8+KLSnNTiQ4zSHCxK4rwO+y5ECAmkJ5akZqemFqQWwWSZODilGhgt912TOP/M 7/HraqPsCzXuHyJjHurx992LW7sjzKRh69uHNc3e5dXG65wuFz0T3Nq2cE5475PM1aZ3ttsw TErZGvpt34ZahVNMduxTLWfrPmhr7X2wbsOdEo5jCsxaqtzygeV1QvH6bzi+7Flk+yt8WXUp x+8GzWmhUfl82+bceKqhNvFbW6cSS3FGoqEWc1FxIgCNxdzxjwIAAA== Archived-At: Subject: [Ice] draft-trickle-11: Comment on section 15 X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2017 08:35:31 -0000 --_000_D55AF3B21DC27christerholmbergericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Section 15 The text says: o A signaling protocol MUST deliver each trickled candidate not more than once and in the same order it was conveyed (see Section 8). - I think you should use MUST NOT deliver more than once terminology. =93MU= ST =85 not more than=94 sounds strange. - This may belong to MMUSIC, but draft-music-trickle-ice-sip defines that e= ach each SIP INFO request (used to carry trickled candidates) contains all = known candidates - including previously trickled ones. Is that aligned with= the requirement above? Regards, Christer --_000_D55AF3B21DC27christerholmbergericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Section 15

The text says:
 o  A signaling protocol MUST deli=
ver each trickled candidate not more
      than once and in the same order it was conveyed (see Section 8).

- I think you should use MUST NOT deliver more than once terminology. = =93MUST =85 not more than=94 sounds strange.

- This may belong to MMUSIC, but draft-music-trickle-ice-sip defines t= hat each each SIP INFO request (used to carry trickled candidates) contains= all known candidates - including previously trickled ones. Is that aligned= with the requirement above? 

Regards,

Christer
--_000_D55AF3B21DC27christerholmbergericssoncom_-- From nobody Mon Jun 5 09:47:39 2017 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E640127866 for ; Mon, 5 Jun 2017 09:47:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 My9kQRgSYd5H for ; Mon, 5 Jun 2017 09:47:35 -0700 (PDT) Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70608120727 for ; Mon, 5 Jun 2017 09:47:35 -0700 (PDT) Received: by mail-oi0-x234.google.com with SMTP id s3so74155688oia.0 for ; Mon, 05 Jun 2017 09:47:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=JAqD/VqiKWZNRpUArdCLiLKn8B+FtP18yhHBBl0LOfM=; b=N5sF+huR4H5r/yd/BmggwnlslJ28qxFmRXsqUHL8a5TSXL/MKSWnQkbPQR8c1St/F5 vfgTSh2/BZNvY5JzkcbJlWrUcZGa+sJETH0mW8P7YXbGUWdrNKCJkMnNOraYmcwB6llG skuvn6RggGKD+U+l2kjU8wNW7IYNXvASdJssU9wY14uFw20sFZlndqcVseH8Us228Kxm F6PA7p8c2Rzb+fv4sKR7HYq4lbkUuNHJ1/0GYQU+nzFjrbZroHmc1tgOlMBfaA3EtklL Jid+2JV6eqLUP8/RldFAbHI0PC4eZYMxeGuln2YZlKZYH4oQwsCq7PZMh8VN8vBCNxMj OroA== 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=JAqD/VqiKWZNRpUArdCLiLKn8B+FtP18yhHBBl0LOfM=; b=rvL8BFV76IimDpI0j6RSkUVWssujU0cV8zPFJT83LSfhpKDMy6/Iur2/0O0ZGPPF+B MCJt2/asGWZ4yalfdi78UeqOBgFeMUE0bQFOhx8xdknVNFl1lp7peKm1jnTtWxgaQfcX HlKZEfBAkJCDKDeEqru9xuSohfIJOxrk48n+ZWHWx7ZCD4/hyEA8BhL7ENYguqoPyX50 meBw/SZIn+d4b9kq8sVEm/fXdCghnBCx2p3wXvjrYwD9UNj2IJyAVrlFqnU/yY/BQEa1 1NW3+UX8SapmRSZ5x5hR3mA0VBkyLwIvqPDBr9/sCdATcPowoLC6SfsTGGyvRUW89/b9 +clQ== X-Gm-Message-State: AODbwcCetI1shewOvZs3Fnbx61wNnNxfPgAKdobThvQiRWJAymgdcqzG sOa57orbDNN5mG1dzzrCi+ft83Ua86z+xCU= X-Received: by 10.157.66.10 with SMTP id q10mr13273715ote.2.1496681254723; Mon, 05 Jun 2017 09:47:34 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Peter Thatcher Date: Mon, 05 Jun 2017 16:47:22 +0000 Message-ID: To: Christer Holmberg , "ice@ietf.org" Content-Type: multipart/alternative; boundary="f4030437969c881f2d0551394289" Archived-At: Subject: Re: [Ice] Peter's review of ICEbis - Why do we model valid candidate pairs as a separate list of separate candidates from the normal check list? X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2017 16:47:37 -0000 --f4030437969c881f2d0551394289 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Ah, so that's the root difference between succeeded and valid. I was wondering what it was. Well, then we can just add a valid state to candidate pairs, which means that it has succeeded and so has its "buddy". On Mon, Jun 5, 2017 at 12:47 AM Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > >Yes, it would be a big change. I'll see if I have some time next week t= o > take a crack at it. > > You can of course always write a PR, but in order not to waste your time = I > think the community should first decide on whether we want to do such > change. > > Also, as your suggestion means that SUCCEEDED means valid, it also remove= s > the current requirement that you need to have SUCCEEDED pairs for EACH > component of a stream in order for a pair to be valid. I know there is a > separate suggestion to remove the component concept, and consider > everything separate streams, so we really need to consider how far we wan= t > to go. > > Regards, > > Christer > > > > On Thu, Jun 1, 2017 at 11:27 PM Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > >> Hi, >> >> >If it's not in any check list, then why not just add it to a check list >> in the Succeeded state? >> >> I haven=E2=80=99t studied it in detail, but I GUESS it could be done tha= t way >> too. Also, implementers can choose to do it that way. >> >> But, repeal of VALID LIST would require quite a bit of work. Also note >> that VALID LIST is used in draft-trickle etc, so I wonder whether it=E2= =80=99s >> worth the effort=E2=80=A6 >> >> Regards, >> >> Christer >> >> >> On Wed, May 31, 2017 at 11:20 PM Christer Holmberg < >> christer.holmberg@ericsson.com> wrote: >> >>> Hi, >>> >>> I need to take one step back. >>> >>> Keep in mind that pairs in the VALID LIST do not necessarily exist in >>> any CHECK LIST. >>> >>> See section 6.2.5.3.2. >>> >>> Regards, >>> >>> Christer >>> >>> From: "pthatcher@google.com" >>> Date: Thursday 1 June 2017 at 04:20 >>> To: Christer Holmberg , "ice@ietf.org" = < >>> ice@ietf.org> >>> Subject: Re: [Ice] Peter's review of ICEbis - Why do we model valid >>> candidate pairs as a separate list of separate candidates from the norm= al >>> check list? >>> >>> What's the different between "valid" and "succeeded"? >>> >>> >>> On Sun, May 28, 2017 at 11:50 PM Christer Holmberg < >>> christer.holmberg@ericsson.com> wrote: >>> >>>> Hi, >>>> >>>> > - Why do we model valid candidate pairs as a separate list of >>>> separate candidates from the normal check list? >>>> > Why not just say that some candidate pairs are valid. Why have this >>>> list of them? Seems like we could remove the concept. >>>> >>>> This is related to an e-mail I sent some time ago, where I asked >>>> whether we really need all states etc, and even suggested we could rem= ove >>>> some of it. However, I then decided not to do it, because it could end= up >>>> in a real mess. >>>> >>>> But, related to your question, when I had a look at it I was thinking >>>> that =E2=80=9CVALID=E2=80=9D could just be a candidate pair state valu= e, rather than a >>>> separate list. >>>> >>>> Regards, >>>> >>>> Christer >>>> >>>> >>>> >>>> --f4030437969c881f2d0551394289 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Ah, so that's the root difference between succeeded an= d valid.=C2=A0 I was wondering what it was.=C2=A0 Well, then we can just ad= d a valid state to candidate pairs, which means that it has succeeded and s= o has its "buddy". =C2=A0

On Mon, Jun 5, 2017 at 12:47 AM Christer Holmberg <christer.holmberg@ericsson.com> wrote:
Hi,

>Yes, it would be a big change.=C2=A0 I'll see if I= have some time next week to take a crack at it.

You can of course always write a PR, but= in order not to waste your time I think the community should first decide = on whether we want to do such change.

Also, as your suggestion means that SUCCEEDED means valid, it also rem= oves the current requirement that you need to have SUCCEEDED pairs for EACH= component of a stream in order for a pair to be valid. I know there is a s= eparate suggestion to remove the component concept, and consider everything separate streams, so we really = need to consider how far we want to go.

Regards,

Christer



Hi,

>If it's not in any check list, then why not just a= dd it to a check list in the Succeeded state? =C2=A0

I haven=E2=80=99t studied it in detail, but I GUESS it could be done t= hat way too. Also, implementers can choose to do it that way.

But, repeal of VALID LIST would require quite a bit of work. Also note= that VALID LIST is used in draft-trickle etc, so I wonder whether it=E2=80= =99s worth the effort=E2=80=A6

Regards,

Christer


On Wed, May 31, 2017 at 11:20 PM Christer Holmberg <christer.h= olmberg@ericsson.com> wrote:
Hi,

I need to take one step back.

Keep in mind that pairs in the VALID LIST do not necessarily exist in = any CHECK LIST.

See section=C2=A06.2.5.3.2.

Regards,

Christer

From: "pthatcher@google.com" <pthatcher@google.com>
Date: Thursday 1 June 2017 at 04:20=
To: Christer Holmberg <christer.holmb= erg@ericsson.com>, "ice@ietf.org" <ice@ietf.org>
Subject: Re: [Ice] Peter's revi= ew of ICEbis - Why do we model valid candidate pairs as a separate list of = separate candidates from the normal check list?

What's the different between "valid" and &qu= ot;succeeded"? =C2=A0


On Sun, May 28, 2017 at 11:50 PM Christer Holmberg <christer.h= olmberg@ericsson.com> wrote:
Hi,

> - Why do we model valid candidate pairs as a separate list of separate= candidates from the normal check list?=C2=A0
>=C2=A0Why not just say = that some candidate pairs are valid.=C2=A0 Why have this list of them? =C2= =A0 =C2=A0Seems like we could remove the concept.

This is related to an e-mail I sent some time ago, where I asked wheth= er we really need all states etc, and even suggested we could remove some o= f it. However, I then decided not to do it, because it could end up in a re= al mess.

But, related to your question, when I had a look at it I was thinking = that =E2=80=9CVALID=E2=80=9D could just be a candidate pair state value, ra= ther than a separate list.

Regards,

Christer



--f4030437969c881f2d0551394289-- From nobody Mon Jun 5 12:59:37 2017 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2894912EB07 for ; Mon, 5 Jun 2017 12:59:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0KLlsHe0Q-2H for ; Mon, 5 Jun 2017 12:59:34 -0700 (PDT) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D166912EB08 for ; Mon, 5 Jun 2017 12:59:32 -0700 (PDT) Received: by mail-wm0-x22c.google.com with SMTP id x70so21210143wme.0 for ; Mon, 05 Jun 2017 12:59:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=1HBE2yiwM55FkW5LAn2gKW513Z7oHJSJIj96HhjtQ4c=; b=HcnGzNMdQZxJ9QwmVrXGMBpPEBOfQKAkPriPLNbwgtgODuPLzV+dsJuJvxZKaDWVHE wkttmLjxdbJAe3aMTFShrSBDGQ4tkir1zSRnnhC8bVmntw8B0Ycw5bhKOXEgsConNIax MTQTPRP+q/WPlySzSfaxT0dvyKpC2wwbyPjN/UXXEMcRQrS+Ofmygi/F9PrO12YYHL1i ljiT/Y5kISClp157HceIdH7B1+IOO5B1MMs5bRdsmuGhO3zZzeerRm8kW4nPe2Pg44pW FtPnHrfpOLlhfU7WPZMFPhqqzaAFX9lkdO/c32pb1n+qZi44C0uD9JIsYRrC7WvElt0P LF5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=1HBE2yiwM55FkW5LAn2gKW513Z7oHJSJIj96HhjtQ4c=; b=b8QXK+PJ2QUFuEz5drFscHyMgX/hFlpkpqoLoUrMIOPU+kbPF3JHe1BsUdqrHnGC5M 8utlHBqCacXmNxGdgSy7VBQ2lkuFzVZLolVjOQlDm5i7YEgrm0QVFGKDSE0OSknD28WI F79Grgf+aLqqDLPbhfiO/P+Kg0/8FlOurnXXue5w0VkWefjxt5c14JqwYZuqftTOXisd q5S7Zr1ExSfdCr3hsiFh2OjzROP23JkI3WUQQ/vGE6aKgL+GpT+BGxwPYbt60bJGRwbj 8HwnmOyqSGMPucE4Ty0Z45brnc0M4N65jEa+eyt8ko23Uuf9I4k31hWpIX8Wiyt4cUIu AM3w== X-Gm-Message-State: AODbwcATNnGdsAAjafaKa3K/0YQ58FCtxOnwgPEFdADsx1BRec/2qHXz XAuuQWAKDC+0Vn34hYg= X-Received: by 10.28.7.16 with SMTP id 16mr9241438wmh.16.1496692770830; Mon, 05 Jun 2017 12:59:30 -0700 (PDT) Received: from [192.168.2.114] (d91-130-4-192.cust.tele2.at. [91.130.4.192]) by smtp.googlemail.com with ESMTPSA id y17sm42691803wrb.39.2017.06.05.12.59.29 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 05 Jun 2017 12:59:30 -0700 (PDT) To: ice@ietf.org References: From: Thomas Stach Message-ID: Date: Mon, 5 Jun 2017 21:59:29 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Ice] draft-trickle-11: Comment on section 15 X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2017 19:59:36 -0000 Christer, On 2017-06-05 10:34, Christer Holmberg wrote: > *Section 15* > * > * > The text says: > o A signaling protocol MUST deliver each trickled candidate not more > than once and in the same order it was conveyed (see Section 8). > > - I think you should use MUST NOT deliver more than once terminology. > “MUST … not more than” sounds strange. > > - This may belong to MMUSIC, but draft-music-trickle-ice-sip defines > that each each SIP INFO request (used to carry trickled candidates) > contains all known candidates - including previously trickled ones. Is > that aligned with the requirement above? The actual text in section 4.2 of draft-music-trickle-ice-sip is as follows, with "agent" meaning a SIP UA and "ICE agent" meaning the entity that actually deals with ICE: Since the agent is not fully aware of the state of the ICE Negotiation Session at its peer it MUST include all currently known and used local candidates in every INFO request. I.e. all candidates that were previously sent under the same combination of "a=ice-pwd:" and "a=ice-ufrag:" need to be repeated. Although repeating all candidates creates some overhead, it also allows easier handling of problems that could arise from unreliable transports, like e.g. loss of messages and reordering, which can be detected through the CSeq: header field in the INFO request. When receiving INFO requests carrying any candidates, agents will therefore first identify and discard the attribute lines containing candidates they have already received in previous INFO requests or in the Offer/Answer exchange preceding them. Two candidates are considered to be equal if their IP address port, transport and component ID are the same. After identifying and discarding known candidates, the ICE agents will then process the remaining, actually new candidates according to the rules described in [I-D.ietf-ice-trickle ]. So, the requirement is covered by the second paragraph. Regards Thomas > > Regards, > > Christer > > > _______________________________________________ > Ice mailing list > Ice@ietf.org > https://www.ietf.org/mailman/listinfo/ice From nobody Mon Jun 5 23:50:15 2017 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD00E126FB3 for ; Mon, 5 Jun 2017 23:50:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m6yaufE7XN_q for ; Mon, 5 Jun 2017 23:50:12 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 034DC1200CF for ; Mon, 5 Jun 2017 23:50:11 -0700 (PDT) X-AuditID: c1b4fb2d-5a49e9a000000d37-33-593650a23826 Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.183.72]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id AF.A5.03383.2A056395; Tue, 6 Jun 2017 08:50:10 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.30]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.03.0339.000; Tue, 6 Jun 2017 08:45:47 +0200 From: Christer Holmberg To: Thomas Stach , "ice@ietf.org" Thread-Topic: [Ice] draft-trickle-11: Comment on section 15 Thread-Index: AQHS3dZ/cBKgt2WVVE+FUUPx8uxmV6IWj0eAgADorQA= Date: Tue, 6 Jun 2017 06:45:47 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.4.170508 x-originating-ip: [153.88.183.18] Content-Type: text/plain; charset="Windows-1252" Content-ID: <1BA1B095B8F4E6479BB9F482E1FD5451@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprEIsWRmVeSWpSXmKPExsUyM2K7h+6iALNIg66nghbfLtRafDqxlcmB yWPnrLvsHkuW/GQKYIrisklJzcksSy3St0vgylh05zprwTXxipc/ehkbGFuFuxg5OSQETCTW 7/jJ2MXIxSEkcIRRYseU1+wQziJGiSXnj7B2MXJwsAlYSHT/0wZpEBHwlJi1Yj4biC0sYCXR NnURI0TcWmLjg9MsELaVRNOHs6wgNouAikTL6ldgNi9QzfeZM8FsIYE8iannlzGD2JwCthIH Ny9iB7EZBcQkvp9awwRiMwuIS9x6Mp8J4lABiSV7zjND2KISLx//AztNVEBP4t1+T4iwosTH V/sYIVoNJN6fm88MYVtLLF66nh3C1pZYtvA1M8Q5ghInZz5hmcAoNgvJtllI2mchaZ+FpH0W kvYFjKyrGEWLU4uLc9ONjPVSizKTi4vz8/TyUks2MQJj6uCW37o7GFe/djzEKMDBqMTDu93G LFKINbGsuDL3EKMEB7OSCC/jXtNIId6UxMqq1KL8+KLSnNTiQ4zSHCxK4rwO+y5ECAmkJ5ak ZqemFqQWwWSZODilGhgNOV5ci3XqXc3Dc/bC1Tq1PY/+7At+ebWgq9n94WKbUwwzBT7kM73e xeCzoL8oWWS7zvsVi+/bN/Ef5nLm1s77ofTi5a3Hf5R22v3VP7bwnXN/P7fs1Onrvj6ve1Rw 9BfzwXt/3T/HiN1bnnz3jKmesfF2/WIObmXrpoK3ag1uF49sfexr5umqxFKckWioxVxUnAgA RGZYE6UCAAA= Archived-At: Subject: Re: [Ice] draft-trickle-11: Comment on section 15 X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2017 06:50:14 -0000 Hi Thomas, The fact that the receiver discards the candidates doesn=B9t change the fac= t that they are *delivered* using the signaling protocol (SIP INFO). So, rather than talking about the singling protocol, perhaps the requirement should be that endpoint need to be able to detect repeated candidates? Regards, Christer On 05/06/17 22:59, "Ice on behalf of Thomas Stach" wrote: >Christer, > > >On 2017-06-05 10:34, Christer Holmberg wrote: >> *Section 15* >> * >> * >> The text says: >> o A signaling protocol MUST deliver each trickled candidate not more >> than once and in the same order it was conveyed (see Section 8). >> >> - I think you should use MUST NOT deliver more than once terminology. >> =B3MUST =8A not more than=B2 sounds strange. >> >> - This may belong to MMUSIC, but draft-music-trickle-ice-sip defines >> that each each SIP INFO request (used to carry trickled candidates) >> contains all known candidates - including previously trickled ones. Is >> that aligned with the requirement above? >The actual text in section 4.2 of draft-music-trickle-ice-sip is as >follows, >with "agent" meaning a SIP UA and "ICE agent" meaning the entity that >actually deals with ICE: > > Since the agent is not fully aware of the state of the ICE > Negotiation Session at its peer it MUST include all currently known > and used local candidates in every INFO request. I.e. all candidates > that were previously sent under the same combination of "a=3Dice-pwd:" > and "a=3Dice-ufrag:" need to be repeated. Although repeating all > candidates creates some overhead, it also allows easier handling of > problems that could arise from unreliable transports, like e.g. loss > of messages and reordering, which can be detected through the CSeq: > header field in the INFO request. > > When receiving INFO requests carrying any candidates, agents will > therefore first identify and discard the attribute lines containing > candidates they have already received in previous INFO requests or in > the Offer/Answer exchange preceding them. Two candidates are > considered to be equal if their IP address port, transport and > component ID are the same. After identifying and discarding known > candidates, the ICE agents will then process the remaining, actually > new candidates according to the rules described in > [I-D.ietf-ice-trickle >ietf-ice-trickle>]. > >So, the requirement is covered by the second paragraph. > >Regards >Thomas > >> >> Regards, >> >> Christer >> >> >> _______________________________________________ >> Ice mailing list >> Ice@ietf.org >> https://www.ietf.org/mailman/listinfo/ice > >_______________________________________________ >Ice mailing list >Ice@ietf.org >https://www.ietf.org/mailman/listinfo/ice From nobody Wed Jun 7 08:46:08 2017 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F26D8127010 for ; Wed, 7 Jun 2017 08:46:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=stpeter.im header.b=M/07OaQT; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=IvRzEEib Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5yXhabKkmnV1 for ; Wed, 7 Jun 2017 08:46:02 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C6131270A3 for ; Wed, 7 Jun 2017 08:46:01 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 3AAE220BB8; Wed, 7 Jun 2017 11:46:01 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute2.internal (MEProxy); Wed, 07 Jun 2017 11:46:01 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stpeter.im; h= content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=tBTvGxvC8tfR79EMYL A+1nrPi+or1ieqdFoc/3yjI0Y=; b=M/07OaQTf7j5bOOcZKjbULna/SjnN1EgRW kBAhKwhq968z8EFvnLmHjv9vgJ7v8oTW50Q9lodsY1fQ6+K2/RCvXl5c3DZ26pXE 9UVyHDvG5s8mSD93C+qKobkDa4AcsatInS6Bumf9034+ll9nM/N8wlIDj3V2mo1S CjsnpdWy4T87UrGXYqfY7MIzcXAGzr8Agnc6/ZW5M6fX9Aosz8YFG96C5FrkznfE dMYpo37LZ0DAGIJqZgzVybsJW/++ph67VD92jymXmn8NKmEUx2odjh4g/DyDc/hf yaz2Vf42hUR/wMCrwqdoeY+lPi0Jg5iHgCDX+9SGH86fUDeT31fw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=tBTvGxvC8tfR79EMYLA+1nrPi+or1ieqdFoc/3yjI0Y=; b=IvRzEEib xbZfgO6DfZ1rIObNmipp58ewcrwItJICTlP7+zlHKNPCVyfYt6IhuY5dvQ0me3j9 0N/Tiat0RtfiqQ7v5OQJnF3ifC6q9xXysu35g/lS9BrRRRCljqx9gfkyj+1Vo9wX 33FLTE2GrffQwCpMPfHwjfgKO0qfixxlV8XJJrAePlIlq2sQE6/8JH/ZajHU0v2y 6jWclBhnhoPd68ORVIo6yebI1i1aNGVv2DGMeOUx/T7hpl6OhnB/YYqvQMXzV6HE o8Bzo8s24/8+9+lTLBWzQe4NQlPHJ5h39vN4EheFoxRdEDSZbEGVNkG5+DRSzQTI R0IVRdOUNKBj/Q== X-ME-Sender: X-Sasl-enc: 2gJBfacJ2dpEuTo3WMP3N4ypYv+LH0xgLvrZVnIzQvTE 1496850360 Received: from aither.local (unknown [76.25.4.24]) by mail.messagingengine.com (Postfix) with ESMTPA id 9691A7E8E5; Wed, 7 Jun 2017 11:46:00 -0400 (EDT) To: Christer Holmberg , "ice@ietf.org" References: From: Peter Saint-Andre Message-ID: <880c3983-c7c8-1660-c84f-48384f594a5e@stpeter.im> Date: Wed, 7 Jun 2017 09:45:58 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Ice] trickle-ice-11: Comment on section 1 (Introduction) X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2017 15:46:07 -0000 On 6/5/17 2:28 AM, Christer Holmberg wrote: > > Hi, > > *Section 1 (Introduction):* > > The text says: > > "This document defines an alternative or supplementary mode of > operation for ICE implementations, known as "Trickle ICE", in which > candidates can be exchanged incrementally. This enables ICE agents > to exchange candidates as soon as an ICE session has been initiated." > > - “alternative or supplementary” sounds strange. I think we can remove > that, and simply say “an operation for ICE implementations,…” Well, it does supplement (not replace) what's defined in 5245bis - I think Emil added those words to make it clear that the trickle mechanism wasn't meant to replace the methods in ICE core. > - I suggest to enhance the second sentence by saying “…as soon as an ICE > session has been initiated an a candidate becomes available.” Makes sense. > - For “ICE session”, please add a reference to draft-5245bis. The > definition for ICE session will show up there in the next version of the > draft (PR exists)… :) Great, thanks! Peter From nobody Thu Jun 8 03:07:48 2017 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BF4112E05C for ; Thu, 8 Jun 2017 03:07:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dvapw6RHE2Sh for ; Thu, 8 Jun 2017 03:07:45 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89E3B129AFA for ; Thu, 8 Jun 2017 03:07:45 -0700 (PDT) X-AuditID: c1b4fb25-73a9f9a0000055fe-c2-593921ef6c57 Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.183.78]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id BF.F2.22014.FE129395; Thu, 8 Jun 2017 12:07:43 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.30]) by ESESSHC020.ericsson.se ([153.88.183.78]) with mapi id 14.03.0339.000; Thu, 8 Jun 2017 12:07:38 +0200 From: Christer Holmberg To: Peter Saint-Andre , "ice@ietf.org" Thread-Topic: [Ice] trickle-ice-11: Comment on section 1 (Introduction) Thread-Index: AQHS36UtYnmcHqVPUESB43+2fAPIYKIa0WIA Date: Thu, 8 Jun 2017 10:07:37 +0000 Message-ID: References: <880c3983-c7c8-1660-c84f-48384f594a5e@stpeter.im> In-Reply-To: <880c3983-c7c8-1660-c84f-48384f594a5e@stpeter.im> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.4.170508 x-originating-ip: [153.88.183.16] Content-Type: text/plain; charset="Windows-1252" Content-ID: <52DD17028EEDA0449C105ECB77C95FD8@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprAIsWRmVeSWpSXmKPExsUyM2K7n+57RctIgyN/JCy+Xai1OLann9mB yWPJkp9MHnP3vGAOYIrisklJzcksSy3St0vgyug49Y+lYCJ7xYL/7ewNjLdYuxg5OSQETCT6 78wCsrk4hASOMEqcndPNCOEsYpQ4uf4vUxcjBwebgIVE9z9tkAYRAU+Ji79XsoHYwgJuEgt/ NLNCxN0l9j29zApSLiJgJPFilxRImEVARaLt3Xewcl4Ba4mWLhCbA2h8vsTcezIgYU4BO4mD aw8wgtiMAmIS30+tYQKxmQXEJW49mc8EcaaAxJI955khbFGJl4//gW0SFdCTeLffEyKsKLHz bDszRKuBxPtz86Fsa4npd3pZIGxtiWULXzNDXCMocXLmE5YJjGKzkGybhaR9FpL2WUjaZyFp X8DIuopRtDi1OCk33chYL7UoM7m4OD9PLy+1ZBMjMJ4ObvmtuoPx8hvHQ4wCHIxKPLyCYpaR QqyJZcWVuYcYJTiYlUR42V9ZRArxpiRWVqUW5ccXleakFh9ilOZgURLnddx3IUJIID2xJDU7 NbUgtQgmy8TBKdXAGO7UF+LpXlhqtkY4Kjbgg8Mukx52lrNVLV/WvFL/GPhg/qT9zq6r+zia Pq9V31Amd6Ar+/5vf5UrTileHv87/tsGc7lairxlefLOmbNYZdlHja1C3Pfciu29TjAr3lq4 7EaTVMKsu/cvJD1M9W9K3L7L2DL9BH/OAtspk+b0ukqFTJJReMihxFKckWioxVxUnAgAW4sT vKMCAAA= Archived-At: Subject: Re: [Ice] trickle-ice-11: Comment on section 1 (Introduction) X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2017 10:07:47 -0000 Hi, >>*Section 1 (Introduction):* >>=20 >> The text says: >>=20 >> "This document defines an alternative or supplementary mode of >> operation for ICE implementations, known as "Trickle ICE", in which >> candidates can be exchanged incrementally. This enables ICE agents >> to exchange candidates as soon as an ICE session has been initiated." >>=20 >> - =B3alternative or supplementary=B2 sounds strange. I think we can remo= ve >> that, and simply say =B3an operation for ICE implementations,=8A=B2 > >Well, it does supplement (not replace) what's defined in 5245bis - I >think Emil added those words to make it clear that the trickle mechanism >wasn't meant to replace the methods in ICE core. Ok, so I can understand the use of =B3supplementary=B2. But, I still don=B9= t get =B3alternative=B2. =B3Alternative=B2 does sound like a replacement :) Regards, Christer From nobody Thu Jun 8 03:11:49 2017 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29BC812E6D7 for ; Thu, 8 Jun 2017 03:11:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 71Ghg9Ja0jUn for ; Thu, 8 Jun 2017 03:11:46 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC4B4124217 for ; Thu, 8 Jun 2017 03:11:45 -0700 (PDT) X-AuditID: c1b4fb30-491ff70000003fda-ec-593922dd821e Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.183.51]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 2B.3F.16346.DD229395; Thu, 8 Jun 2017 12:11:44 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.30]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.03.0339.000; Thu, 8 Jun 2017 12:11:45 +0200 From: Christer Holmberg To: Peter Thatcher , "ice@ietf.org" Thread-Topic: [Ice] Peter's review of ICEbis - Why do we model valid candidate pairs as a separate list of separate candidates from the normal check list? Thread-Index: AQHS2EfLSJWiXi6t0kqXcQwCFgzNt6IPGIOAgACHTICAAP3NgIAAlhAAgADZ1ICAA/QFAIAAYzIAgAR8iwA= Date: Thu, 8 Jun 2017 10:11:44 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.4.170508 x-originating-ip: [153.88.183.19] Content-Type: multipart/alternative; boundary="_000_D55EFE2D1E008christerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprPIsWRmVeSWpSXmKPExsUyM2K7se4DJctIg5XPmSy+Xai1uLb8NasD k8eCTaUeS5b8ZApgiuKySUnNySxLLdK3S+DKaH30hKngRF7F/+nODYzr47sYOTkkBEwk3i+4 ydjFyMUhJHCEUeLT5N8sEM4iRomzD06zdzFycLAJWEh0/9MGaRAR8JDY/GY5G0iNsMBcRonr X/cwgzgiAvMYJX4vn8UMUZUksfHbdDCbRUBF4v/Xh2A2r4C1RP+s/WwQG94ySyxcOokFJMEp EChx49Q3VhCbUUBM4vupNUwgNrOAuMStJ/OZIG4VkFiy5zwzhC0q8fLxP1aQ60QF9CTe7feE CCtKtD9tYIRoTZBY83oNC8ReQYmTM5+wTGAUmYVk6iwkZbOQlEHEDSTen5vPDGFrSyxb+BrK 1pfY+OUsI4RtLfHwzBwmZDULGDlWMYoWpxYn5aYbGemlFmUmFxfn5+nlpZZsYgRG28Etvw12 ML587niIUYCDUYmH10PUMlKINbGsuDL3EKMEB7OSCC/7K4tIId6UxMqq1KL8+KLSnNTiQ4zS HCxK4ryO+y5ECAmkJ5akZqemFqQWwWSZODilGhjlnh5be+zvZk7lk9MfMj7lKn218Zl43GGh wjX39O/JzmzdbCx8S7de9RvjvmMh3KJlVio8LW+KD2gu/mCXsk9sc4CizKGTW8syJvpNYczb YG5+Mv7uEulJ851d/INZv9x6e9RQ7/LX/hs/H31KvZJu5L/ez+jQlOdJkap7Wv0/2/VfX9jz +WKAEktxRqKhFnNRcSIAQD9lCbICAAA= Archived-At: Subject: Re: [Ice] Peter's review of ICEbis - Why do we model valid candidate pairs as a separate list of separate candidates from the normal check list? X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2017 10:11:48 -0000 --_000_D55EFE2D1E008christerholmbergericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, > Ah, so that's the root difference between succeeded and valid. I was won= dering what it was. Well, then we can just add a valid state to candidate = pairs, which means that it has succeeded and so has its "buddy". Assuming the order of pairs in the valid list doesn=92t matter, I guess it = could be done that way (I wouldn=92t be surprised if that=92s how some impl= ementations are done). Regards, Christer On Mon, Jun 5, 2017 at 12:47 AM Christer Holmberg > wrote: Hi, >Yes, it would be a big change. I'll see if I have some time next week to = take a crack at it. You can of course always write a PR, but in order not to waste your time I = think the community should first decide on whether we want to do such chang= e. Also, as your suggestion means that SUCCEEDED means valid, it also removes = the current requirement that you need to have SUCCEEDED pairs for EACH comp= onent of a stream in order for a pair to be valid. I know there is a separa= te suggestion to remove the component concept, and consider everything sepa= rate streams, so we really need to consider how far we want to go. Regards, Christer On Thu, Jun 1, 2017 at 11:27 PM Christer Holmberg > wrote: Hi, >If it's not in any check list, then why not just add it to a check list in= the Succeeded state? I haven=92t studied it in detail, but I GUESS it could be done that way too= . Also, implementers can choose to do it that way. But, repeal of VALID LIST would require quite a bit of work. Also note that= VALID LIST is used in draft-trickle etc, so I wonder whether it=92s worth = the effort=85 Regards, Christer On Wed, May 31, 2017 at 11:20 PM Christer Holmberg > wrote: Hi, I need to take one step back. Keep in mind that pairs in the VALID LIST do not necessarily exist in any C= HECK LIST. See section 6.2.5.3.2. Regards, Christer From: "pthatcher@google.com" > Date: Thursday 1 June 2017 at 04:20 To: Christer Holmberg >, "ice@ietf.org" > Subject: Re: [Ice] Peter's review of ICEbis - Why do we model valid candida= te pairs as a separate list of separate candidates from the normal check li= st? What's the different between "valid" and "succeeded"? On Sun, May 28, 2017 at 11:50 PM Christer Holmberg > wrote: Hi, > - Why do we model valid candidate pairs as a separate list of separate ca= ndidates from the normal check list? > Why not just say that some candidate pairs are valid. Why have this list= of them? Seems like we could remove the concept. This is related to an e-mail I sent some time ago, where I asked whether we= really need all states etc, and even suggested we could remove some of it.= However, I then decided not to do it, because it could end up in a real me= ss. But, related to your question, when I had a look at it I was thinking that = =93VALID=94 could just be a candidate pair state value, rather than a separ= ate list. Regards, Christer --_000_D55EFE2D1E008christerholmbergericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <92B3C1FC184E2340B939D08E3D883A1A@ericsson.com> Content-Transfer-Encoding: quoted-printable
Hi,

> Ah, so that's the root difference between succeeded a= nd valid.  I was wondering what it was.  Well, then we can just a= dd a valid state to candidate pairs, which means that it has succeeded and = so has its "buddy".  

Assuming the order of pairs in the valid list doesn=92t matter, I gues= s it could be done that way (I wouldn=92t be surprised if that=92s how some= implementations are done).

Regards,

Christer




On Mon, Jun 5, 2017 at 12:47 AM Christer Holmberg <christer.holmberg@ericsson.co= m> wrote:
Hi,

>Yes, it would be a big change.  I'll see if I hav= e some time next week to take a crack at it.

You can of course always write a PR, but in order not to waste your ti= me I think the community should first decide on whether we want to do such = change.

Also, as your suggestion means that SUCCEEDED means valid, it also rem= oves the current requirement that you need to have SUCCEEDED pairs for EACH= component of a stream in order for a pair to be valid. I know there is a s= eparate suggestion to remove the component concept, and consider everything separate streams, so we really = need to consider how far we want to go.

Regards,

Christer



On Thu, Jun 1, 2017 at 11:27 PM Christer Holmberg <christer.ho= lmberg@ericsson.com> wrote:
Hi,

>If it's not in any check list, then why not just add i= t to a check list in the Succeeded state?  

I haven=92t studied it in detail, but I GUESS it could be done that wa= y too. Also, implementers can choose to do it that way.

But, repeal of VALID LIST would require quite a bit of work. Also note= that VALID LIST is used in draft-trickle etc, so I wonder whether it=92s w= orth the effort=85

Regards,

Christer


On Wed, May 31, 2017 at 11:20 PM Christer Holmberg <christer.h= olmberg@ericsson.com> wrote:
Hi,

I need to take one step back.

Keep in mind that pairs in the VALID LIST do not necessarily exist in = any CHECK LIST.

See section 6.2.5.3.2.

Regards,

Christer

From: "pthatcher@google.com" <pthatcher@google.com>
Date: Thursday 1 June 2017 at 04:20=
To: Christer Holmberg <christer.holmb= erg@ericsson.com>, "ice@ietf.org" <ice@ietf.org>
Subject: Re: [Ice] Peter's review o= f ICEbis - Why do we model valid candidate pairs as a separate list of sepa= rate candidates from the normal check list?

What's the different between "valid" and "s= ucceeded"?  


On Sun, May 28, 2017 at 11:50 PM Christer Holmberg <christer.h= olmberg@ericsson.com> wrote:
Hi,

> - Why do we model valid candidate pairs as a separate list of separate= candidates from the normal check list? 
> Why not just say = that some candidate pairs are valid.  Why have this list of them? &nbs= p;  Seems like we could remove the concept.

This is related to an e-mail I sent some time ago, where I asked wheth= er we really need all states etc, and even suggested we could remove some o= f it. However, I then decided not to do it, because it could end up in a re= al mess.

But, related to your question, when I had a look at it I was thinking = that =93VALID=94 could just be a candidate pair state value, rather than a = separate list.

Regards,

Christer



 --_000_D55EFE2D1E008christerholmbergericssoncom_-- From nobody Thu Jun 8 05:34:56 2017 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1FDE129BCA for ; Thu, 8 Jun 2017 05:34:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=stpeter.im header.b=YQReAJYE; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=r1BK/sGl Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CN0J8_VNZZTI for ; Thu, 8 Jun 2017 05:34:53 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1AF371287A7 for ; Thu, 8 Jun 2017 05:34:52 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 6154220ABE; Thu, 8 Jun 2017 08:34:52 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute2.internal (MEProxy); Thu, 08 Jun 2017 08:34:52 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stpeter.im; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=lTVIiFhyAVsTpVCQ89 Kj05i6dF8hBYSc2ke8XOEE0v0=; b=YQReAJYEu+Jokl3h8brWAzM3q9IAJl2Fzj rnIdq6ZOr78a285e966vECbmYJ9KkIQ9plyNZe3UGaTtB6+crxZc+oPL6YGZ7e2o ju6gvJ7dIyKyZYBohxDwgYofyGz2bTXPzsmFdLYCHDXHu5UNsSHwUOnaJcW+S/ZI MsSuTfWi9BA1nZLiTp49MrT6SPt6V1ub+MXuXPmkMAoA+x0Iz/2fmq9Q55uu2ySx z0HyR7f+oZMR/0aWsVQRXm45lDAGbuu+W7gNhDMMaWbWCWj//MumfEpOt8443XPU uMA2QGfFyV+te4dr5U6mNAaSuJYF7hvPGVxMiciL5JqD9Q97w09g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=lTVIiFhyAVsTpVCQ89Kj05i6dF8hBYSc2ke8XOEE0v0=; b=r1BK/sGl i+3B49Lpq0xV80wlS1F0COvBO+w9naRq+eQkaObHSvtZw/EcUwFgG/6Vwu0Y6ElP P2uaBZODZnPGlmKNvbdty4uRCDzfvWHB8w6yHo0AAjIlguJp6tCm6eHHR/NrlyYU MTpM9HGQpChWFz3alohCx1Gc1+GhuiEP2PYlAQDab07SC7hFnmxB1hvw2yXKGfnI +LLbBUeF4ejNSvX5PdeeAe/Wkb/cjbM1/5KG9d82OVfTWN8uHsWBu3dFjDjgSyrW n6vmalgbeHs/e4ZxiG6pXUpialF69JZKRw3mpZvxOza14OdCafdVk9OlLyUeKkL7 aHIiYXEPSQ2Tjg== X-ME-Sender: X-Sasl-enc: chEbXolYq3IgkE/0k9XDAy0bq2A42jewjNC1ULM0Q8r0 1496925292 Received: from [10.0.0.228] (unknown [76.25.4.24]) by mail.messagingengine.com (Postfix) with ESMTPA id 105A47E88C; Thu, 8 Jun 2017 08:34:52 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) From: Peter Saint-Andre In-Reply-To: Date: Thu, 8 Jun 2017 05:56:37 -0600 Cc: "ice@ietf.org" Message-Id: References: <880c3983-c7c8-1660-c84f-48384f594a5e@stpeter.im> To: Christer Holmberg X-Mailer: iPhone Mail (14F89) Archived-At: Subject: Re: [Ice] trickle-ice-11: Comment on section 1 (Introduction) X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2017 12:34:55 -0000 > On Jun 8, 2017, at 4:07 AM, Christer Holmberg wrote: >=20 > Hi, >=20 >>> *Section 1 (Introduction):* >>>=20 >>> The text says: >>>=20 >>> "This document defines an alternative or supplementary mode of >>> operation for ICE implementations, known as "Trickle ICE", in which >>> candidates can be exchanged incrementally. This enables ICE agents >>> to exchange candidates as soon as an ICE session has been initiated." >>>=20 >>> - =C2=B3alternative or supplementary=C2=B2 sounds strange. I think we ca= n remove >>> that, and simply say =C2=B3an operation for ICE implementations,=C5=A0=C2= =B2 >>=20 >> Well, it does supplement (not replace) what's defined in 5245bis - I >> think Emil added those words to make it clear that the trickle mechanism >> wasn't meant to replace the methods in ICE core. >=20 > Ok, so I can understand the use of =C2=B3supplementary=C2=B2. But, I still= don=C2=B9t get > =C2=B3alternative=C2=B2. =C2=B3Alternative=C2=B2 does sound like a replace= ment :) >=20 > Regards, >=20 > Christer >=20 Right - I suggest that we remove "alternative". Peter= From nobody Thu Jun 8 09:38:01 2017 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B459129473 for ; Thu, 8 Jun 2017 09:37:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 87o6cNsJyf17 for ; Thu, 8 Jun 2017 09:37:57 -0700 (PDT) Received: from mail-ot0-x22d.google.com (mail-ot0-x22d.google.com [IPv6:2607:f8b0:4003:c0f::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03704129469 for ; Thu, 8 Jun 2017 09:37:57 -0700 (PDT) Received: by mail-ot0-x22d.google.com with SMTP id a2so26189599oth.2 for ; Thu, 08 Jun 2017 09:37:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=M/vhrx9KFSFYgCsEgfEDfjv+d609NP7/QFyNKCO7QK8=; b=NwflXbBIiqMpT4nu3W+U8Uo9RhRpvlM9dDaRCxW0wdB/Wde/ujk8YYUar3xRMQR885 Fs1LxOr6CDgF8rGQZUFHuBVzEo44W0YWEoN8jfamBlJbUCvjKQKFite+oeDK+mybmdrW KLXGf3dkmcEc/ayHgc4NcqW9SM0ybaQPVUdLhV4Cpl9/yLBXQUvXGXNrO0kJDvs761/9 2D7OfzL9Aqf21WmThQNDqf9YKM/AtsbQjpvm1YPB1fFwSkoafLvDd8wrxltt8mSxdZSD Q4+kl0GJ94phM/mTzDVIPPTAXSI9ojn0SMsdA/QdL2LjR/BRWTgkhvK91YPUWpjP3R3a pS6g== 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=M/vhrx9KFSFYgCsEgfEDfjv+d609NP7/QFyNKCO7QK8=; b=s9I2jsc0/vUbHsrufqWOdniH9PdTNnNfgcwUufATM5e7UixMQfxAsZ9wlihKezFMLc iAq7uzokOZ0X1SNtEsk8BsfZdsm8k6g3+ipwXtrN2fmMsbGihCY9TX1ErpXZy2SwekLu H0P/h5Ho+k+3apUX+hM+rQ7sz73PssiQ594Sx7hfrLA7BK0XDl5QG5ka4VDQTbFT1L0t 82+VJoTsJeFBFegyA6f766uO4ESuvfEwFhZtrowPilZrvMmCEnD+/MWEZpeBV/HdfVBI QurfuuXRmdI4O40peTuQ1Mt80jO7KYFo2I2yJFsjaQ2S+w5R29QFYsgxV32/7s+6LQId D+RA== X-Gm-Message-State: AODbwcBUbgM//K2YN1v1vqkd+gDjJBeUd77MRUb1tDsvdkLQb6a8whzp 7ruX9qGLr40lt1fAWhtAkgsYFGFqsRRg X-Received: by 10.157.35.10 with SMTP id j10mr22592967otb.258.1496939876311; Thu, 08 Jun 2017 09:37:56 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Peter Thatcher Date: Thu, 08 Jun 2017 16:37:45 +0000 Message-ID: To: Christer Holmberg , "ice@ietf.org" Content-Type: multipart/alternative; boundary="001a114080149450800551757980" Archived-At: Subject: Re: [Ice] Peter's review of ICEbis - Why do we model valid candidate pairs as a separate list of separate candidates from the normal check list? X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2017 16:37:59 -0000 --001a114080149450800551757980 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable That's how ours is done :). On Thu, Jun 8, 2017 at 3:11 AM Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > > Ah, so that's the root difference between succeeded and valid. I was > wondering what it was. Well, then we can just add a valid state to > candidate pairs, which means that it has succeeded and so has its "buddy"= . > > Assuming the order of pairs in the valid list doesn=E2=80=99t matter, I g= uess it > could be done that way (I wouldn=E2=80=99t be surprised if that=E2=80=99s= how some > implementations are done). > > Regards, > > Christer > > > > > On Mon, Jun 5, 2017 at 12:47 AM Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > >> Hi, >> >> >Yes, it would be a big change. I'll see if I have some time next week >> to take a crack at it. >> >> You can of course always write a PR, but in order not to waste your time >> I think the community should first decide on whether we want to do such >> change. >> >> Also, as your suggestion means that SUCCEEDED means valid, it also >> removes the current requirement that you need to have SUCCEEDED pairs fo= r >> EACH component of a stream in order for a pair to be valid. I know there= is >> a separate suggestion to remove the component concept, and consider >> everything separate streams, so we really need to consider how far we wa= nt >> to go. >> >> Regards, >> >> Christer >> >> >> >> On Thu, Jun 1, 2017 at 11:27 PM Christer Holmberg < >> christer.holmberg@ericsson.com> wrote: >> >>> Hi, >>> >>> >If it's not in any check list, then why not just add it to a check lis= t >>> in the Succeeded state? >>> >>> I haven=E2=80=99t studied it in detail, but I GUESS it could be done th= at way >>> too. Also, implementers can choose to do it that way. >>> >>> But, repeal of VALID LIST would require quite a bit of work. Also note >>> that VALID LIST is used in draft-trickle etc, so I wonder whether it=E2= =80=99s >>> worth the effort=E2=80=A6 >>> >>> Regards, >>> >>> Christer >>> >>> >>> On Wed, May 31, 2017 at 11:20 PM Christer Holmberg < >>> christer.holmberg@ericsson.com> wrote: >>> >>>> Hi, >>>> >>>> I need to take one step back. >>>> >>>> Keep in mind that pairs in the VALID LIST do not necessarily exist in >>>> any CHECK LIST. >>>> >>>> See section 6.2.5.3.2. >>>> >>>> Regards, >>>> >>>> Christer >>>> >>>> From: "pthatcher@google.com" >>>> Date: Thursday 1 June 2017 at 04:20 >>>> To: Christer Holmberg , "ice@ietf.org" >>>> >>>> Subject: Re: [Ice] Peter's review of ICEbis - Why do we model valid >>>> candidate pairs as a separate list of separate candidates from the nor= mal >>>> check list? >>>> >>>> What's the different between "valid" and "succeeded"? >>>> >>>> >>>> On Sun, May 28, 2017 at 11:50 PM Christer Holmberg < >>>> christer.holmberg@ericsson.com> wrote: >>>> >>>>> Hi, >>>>> >>>>> > - Why do we model valid candidate pairs as a separate list of >>>>> separate candidates from the normal check list? >>>>> > Why not just say that some candidate pairs are valid. Why have >>>>> this list of them? Seems like we could remove the concept. >>>>> >>>>> This is related to an e-mail I sent some time ago, where I asked >>>>> whether we really need all states etc, and even suggested we could re= move >>>>> some of it. However, I then decided not to do it, because it could en= d up >>>>> in a real mess. >>>>> >>>>> But, related to your question, when I had a look at it I was thinking >>>>> that =E2=80=9CVALID=E2=80=9D could just be a candidate pair state val= ue, rather than a >>>>> separate list. >>>>> >>>>> Regards, >>>>> >>>>> Christer >>>>> >>>>> >>>>> >>>>> --001a114080149450800551757980 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
That's how ours is done :). =C2=A0

On Thu, Jun 8, 2017 at 3:11 AM Christer H= olmberg <christer.holm= berg@ericsson.com> wrote:
Hi,

> Ah, so that's the root difference between succeed= ed and valid.=C2=A0 I was wondering what it was.=C2=A0 Well, then we can ju= st add a valid state to candidate pairs, which means that it has succeeded = and so has its "buddy". =C2=A0

Assuming the order of pairs in the valid= list doesn=E2=80=99t matter, I guess it could be done that way (I wouldn= =E2=80=99t be surprised if that=E2=80=99s how some implementations are done= ).

Regards,

Christer




On Mon, Jun 5, 2017 at 12:47 AM Christer Holmberg <christer.ho= lmberg@ericsson.com> wrote:
Hi,

>Yes, it would be a big change.=C2=A0 I'll see if I= have some time next week to take a crack at it.

You can of course always write a PR, but in order not to waste your ti= me I think the community should first decide on whether we want to do such = change.

Also, as your suggestion means that SUCCEEDED means valid, it also rem= oves the current requirement that you need to have SUCCEEDED pairs for EACH= component of a stream in order for a pair to be valid. I know there is a s= eparate suggestion to remove the component concept, and consider everything separate streams, so we really = need to consider how far we want to go.

Regards,

Christer



On Thu, Jun 1, 2017 at 11:27 PM Christer Holmberg <christer.ho= lmberg@ericsson.com> wrote:
Hi,

>If it's not in any check list, then why not just a= dd it to a check list in the Succeeded state? =C2=A0

I haven=E2=80=99t studied it in detail, but I GUESS it could be done t= hat way too. Also, implementers can choose to do it that way.

But, repeal of VALID LIST would require quite a bit of work. Also note= that VALID LIST is used in draft-trickle etc, so I wonder whether it=E2=80= =99s worth the effort=E2=80=A6

Regards,

Christer


On Wed, May 31, 2017 at 11:20 PM Christer Holmberg <christer.h= olmberg@ericsson.com> wrote:
Hi,

I need to take one step back.

Keep in mind that pairs in the VALID LIST do not necessarily exist in = any CHECK LIST.

See section=C2=A06.2.5.3.2.

Regards,

Christer

From: "pthatcher@google.com" <pthatcher@google.com>
Date: Thursday 1 June 2017 at 04:20=
To: Christer Holmberg <christer.holmb= erg@ericsson.com>, "ice@ietf.org" <ice@ietf.org>
Subject: Re: [Ice] Peter's revi= ew of ICEbis - Why do we model valid candidate pairs as a separate list of = separate candidates from the normal check list?

What's the different between "valid" and &qu= ot;succeeded"? =C2=A0


On Sun, May 28, 2017 at 11:50 PM Christer Holmberg <christer.h= olmberg@ericsson.com> wrote:
Hi,

> - Why do we model valid candidate pairs as a separate list of separate= candidates from the normal check list?=C2=A0
>=C2=A0Why not just say = that some candidate pairs are valid.=C2=A0 Why have this list of them? =C2= =A0 =C2=A0Seems like we could remove the concept.

This is related to an e-mail I sent some time ago, where I asked wheth= er we really need all states etc, and even suggested we could remove some o= f it. However, I then decided not to do it, because it could end up in a re= al mess.

But, related to your question, when I had a look at it I was thinking = that =E2=80=9CVALID=E2=80=9D could just be a candidate pair state value, ra= ther than a separate list.

Regards,

Christer
--001a114080149450800551757980-- From nobody Thu Jun 8 19:54:51 2017 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95E981294C4 for ; Thu, 8 Jun 2017 19:54:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=stpeter.im header.b=BIIeDOBz; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=BsQCYBcp Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qaOLWDO7cvGI for ; Thu, 8 Jun 2017 19:54:48 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 797CE1294B2 for ; Thu, 8 Jun 2017 19:54:48 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id CC71920B57; Thu, 8 Jun 2017 22:54:47 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute2.internal (MEProxy); Thu, 08 Jun 2017 22:54:47 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stpeter.im; h= content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=JkmXIX2DXyZEciK7Sp Jhp9ggfuV9vGT8UXHvwMeG2fw=; b=BIIeDOBzmEhMt6YJpkKYTYZ+2cYNVI31DR jZV3h3efizCxvbPRYpdi80b5SaUTLhrr5kTQOuill6Dg+0WdvJdtbfyhxxGV7vYG 7rGUhXs95Dyc8MfwB2imz6px7aiewk/r/rL47KzTt5FvNsQbWCe9GdgQ3fc0T2/d dXI3OEqHdpvnUIGEQTxMZil3H1+CZr6hbeEazPpxxMAv7oAtoEFOUneSTgesXlzd gDQGwowp3oBsCwMFNARz8r4GYOGa1cBdAmQ+Mda9wsPnri0Lg8Kal5LuDz2NoOyn 7qfFsre5MX9cV3F2K4MY/jTSeLvhQBqhY+Qqj1UKJb0L7u1BsmBw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=JkmXIX2DXyZEciK7SpJhp9ggfuV9vGT8UXHvwMeG2fw=; b=BsQCYBcp jiuYV+tsxmMxSfuWLhYCo9AQ+xs1noyZdePqVmaUHYQ7VhuLGXExewhYPXhEt0FC frn1RB08ETxzV32t4MYhWjW1zEQorL7wkLFTxPdDDf0za44H+fiMq8KTRkiLN+pm f9UVURSYekw3Rez3V/Zrm7juQ8x6pgQRiJhp/VYB1ky2njeMvoUNyCoq2W9z6p4n 5URaYJ3vJ/hJfqSu7vekFeL0+iL9lagYqcIK2UhKaWneEwQxjXwW3fpYciBrPQMX MwsetFYKzkcS9U+J+4UlF3sQZ70Z6M55cjmUq+tOigWF//z0DxAtLYG17d8WQPPY tTHEYXAtnnvhVw== X-ME-Sender: X-Sasl-enc: sTao7tu+mzYouUybeAFDICaj9pWk88wOjqYEWPcdn3uV 1496976887 Received: from aither.local (unknown [76.25.4.24]) by mail.messagingengine.com (Postfix) with ESMTPA id 4D1E17E7A3; Thu, 8 Jun 2017 22:54:47 -0400 (EDT) To: Christer Holmberg , "ice@ietf.org" References: From: Peter Saint-Andre Message-ID: <4cd3114a-80bf-33a5-24d7-14b277a3758a@stpeter.im> Date: Thu, 8 Jun 2017 20:54:45 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Ice] draft-trickle-11: Comment on section 2 (Terminology) X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2017 02:54:51 -0000 On 6/5/17 2:29 AM, Christer Holmberg wrote: > > *Section 2 (Terminology)* > > There is a definition for “candidate gatherer”. Do we really need that? > There is no such thing in 5245bis, and I fail to see why trickle would > need it. This is probably an implementation detail that we can leave out. > I don’t think the “ICE parameter” definition is aligned with 5245bis. > 5245bis doesn’t seem to have a clear definition of “ICE parameter” > (perhaps we should fix that), That would be helpful. Then we can just include that definition reference in the trickle spec. > but it doesn’t seem to exclude candidate > specific parameters. The closest I find is in Section 17.4 of 5245bis: ICE parameters .... include the type of each candidate (host, server reflexive, or relayed), along with their related addresses. > Also, in the definition for “Full Trickle” it seems to indicate that ICE > parameters can carry candidates. Also later in the document there is > text about using ICE parameters to carry candidates. Good catch. This is likely an artifact of changing many instances of "ICE Description" to "ICE Parameters" in version -09, which we did because Taylor felt that "ICE Description" sounded too much like an offer/answer construct. > I think using “ICE parameters” in these definitions is confusing. We could, of course, just go back to the phrase "ICE Description" - personally I didn't feel that was a bad phrase and I think Emil felt the same. > Shouldn’t we talk about candidates that are individually exchanged > at some point, once the ICE session has been initiated, before the > nomination? Sure. The point of "ICE description" or "initial ICE description" was that in trickle the agent doesn't necessarily include candidates in the initial description, because all the candidates are sent (trickled) after that point. Peter From nobody Thu Jun 8 19:59:20 2017 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FB861242F7 for ; Thu, 8 Jun 2017 19:59:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=stpeter.im header.b=hqKD9UhW; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=QUVkNrO2 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n7Axdt4UprSQ for ; Thu, 8 Jun 2017 19:59:15 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C62F1200F3 for ; Thu, 8 Jun 2017 19:59:15 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id E4F772094B; Thu, 8 Jun 2017 22:59:14 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute2.internal (MEProxy); Thu, 08 Jun 2017 22:59:14 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stpeter.im; h= content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=O+Km+OLzWdPIuvupiD f5Kd5U74FZmo9QWdxTTDFjl+s=; b=hqKD9UhWwq03ptPbCb2bhTlO914u6xOVdd EdSjDq9BaGXFEraltr1tJFwvXrkYxyOpF7LeHXr73XGW+RKMgjnZqNBvKQ35lr3u 4GyCgEciF1SETJlJ2NcTUQayIjvc/xNHZTd5vJc3sIv+UsOd8doh7Pg+h6NVPeT3 xRkQPRlnkBsXsF5gNV72SIln1hy73/ldd0lHSIy5BH9oVVitUaV7oj+VYmvYYcWH 4zEqYSCpJMozKSen3LO2kFY0Ga25Z4wFvBriZWHRDd566EOTNUstl2zZg7aUCdwk CMVwPN9EGJaUdljCrAkwcFBxNyBIR4nHNGO8rDDp714HavgLqT1A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=O+Km+OLzWdPIuvupiDf5Kd5U74FZmo9QWdxTTDFjl+s=; b=QUVkNrO2 MtQdLxXwq4feO+C1aZmmbMUGJFQPFAKy18OV1kNV34YBAhLekms9sB5kacrF+mDX mFXSDv+/sm1Ubdxd1P+LAw0TQF6IJ9J6Jv2pVw/8ouUBekvU7Rmo9OHXOtoIoZfz VdcoWV2PmoqhI8O8SyiERbsKtGqnTSZF76HI3RFF+QpGJg0q2EUyDOBe7X0VhOe8 MVI0ls/ozfO2hc9rELQEf4H5fU8FO/H1VIY5bZ7TjuZHIcw0KJKPtNncdN7UcFEC h8tLLqfARX0XBNWbyOB1v4jwysgP6v84XqQifr1P5mTvNhmfU/a2QVpANzhPesCH 2RzoQ2maEk3WDg== X-ME-Sender: X-Sasl-enc: eKVscF3s4LwlOVKqOfbH0+XGb9tBLZy6gH13z5i4/sLx 1496977154 Received: from aither.local (unknown [76.25.4.24]) by mail.messagingengine.com (Postfix) with ESMTPA id 6F2E87E5F1; Thu, 8 Jun 2017 22:59:14 -0400 (EDT) To: Christer Holmberg , "ice@ietf.org" References: From: Peter Saint-Andre Message-ID: <0b357375-8759-ee20-9ca5-a473ffa92cb0@stpeter.im> Date: Thu, 8 Jun 2017 20:59:13 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Ice] draft-trickle-11: Comment on section 3 X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2017 02:59:18 -0000 On 6/5/17 2:30 AM, Christer Holmberg wrote: > *Section 3* > > The text says: > > "If an agent determines that the remote party does not support Trickle ICE, it > MUST fall back to using regular ICE or abandon the entire session." > > This is confusing, because earlier the draft says that half trickle can > be used if the remote party doesn’t support trickle. Section 2 states: The [half trickle] mechanism is mostly meant for use in cases where the remote agent's support for Trickle ICE cannot be confirmed prior to conveying the initial ICE parameters. Not being able to determine the remote agent's support for trickle is different from definitively determining that the remote agent does not support trickle (the case covered by the text in Section 3). If this is not sufficiently clear, we can improve the text. > And, I don’t think > “regular ICE” and “half trickle” are the same things, are they? I don't think the spec implies that they are. Peter From nobody Thu Jun 8 20:07:34 2017 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6940129408 for ; Thu, 8 Jun 2017 20:07:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=stpeter.im header.b=EiN5Sm2T; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=fzpBzbWB Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id le1OD1GbC4be for ; Thu, 8 Jun 2017 20:07:32 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B6CB128CDB for ; Thu, 8 Jun 2017 20:07:32 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id A82E320BDD; Thu, 8 Jun 2017 23:07:31 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute2.internal (MEProxy); Thu, 08 Jun 2017 23:07:31 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stpeter.im; h= content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=X8eJnQirsmyyqy+0uO oBv40L2jF/7CWHSYBo3PShNNs=; b=EiN5Sm2TFVYW8qphphA1V/L+VGwGt4n4Xz wH3ju2kiLX5TGZdhEOG+44b2bLWpNFrA2XlfmI9/1Xk5gDHLGYkGw4XE2d4HYRbl 5RBNTxPSUMPBKwzKRFIWo+Fqm8tKASWc/MKBU0HgLQkiAU9uljTGkfGp24funcZZ CdArAQK8rtBhgGeTFCtinqUu0LJ1l3MceHkr5io9UBou7XEoUxpMUVQxknO9wksJ GYE+whCiX4oOqPeapaJybDnc0qW0HHc2J3XHZ0Jh/BQ6RGQZhe948GUfxF0T2G1X JiDir7CbTK7FheDqrhFw5VCztvPhzSGSSTNY2WGa++l7rZ/4aH6g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=X8eJnQirsmyyqy+0uOoBv40L2jF/7CWHSYBo3PShNNs=; b=fzpBzbWB SbVnMiPuHHkj2ot4o3LkoM8IP2d527FE/9JjcF6U1jserTrULBpKJZaROfX3jE6A e51fnTEiDsMwQmKMIhoGCQcJ7un/QZTrd/lyOeRo2bJuYqmkycBQW/HxVKjSgjvo PzZvaIm7yQPq2HcLmCZ2SJGw07r7PUtcLttx7gPQb9kciq+Za2ThCnjtbAlXdS5/ giTEYUAw+Xy/VIXmCAdhmlUQ4UeAfcENhbxVXtV4JyibFghMj/oaw5TmAolrt+2G 7SOYqV5CNMjWYUYf4KO2ieZNCfjKzcc4hqVO74mWYj5WAFipGiFgzO7eCfzRPZm/ Zh58lCNECokbDQ== X-ME-Sender: X-Sasl-enc: 1HAcV2f+rHovHuq1726VBG/vLjVG0X+62Rpg0eA8K+HY 1496977651 Received: from aither.local (unknown [76.25.4.24]) by mail.messagingengine.com (Postfix) with ESMTPA id 30AAB7E545; Thu, 8 Jun 2017 23:07:30 -0400 (EDT) To: Christer Holmberg , "ice@ietf.org" References: From: Peter Saint-Andre Message-ID: <7faa5d37-6788-3766-0a74-9eab06c240f9@stpeter.im> Date: Thu, 8 Jun 2017 21:07:30 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Ice] draft-trickle-11: Comment on section 5 X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2017 03:07:33 -0000 On 6/5/17 2:30 AM, Christer Holmberg wrote: > *Section 5* > > The text says: > > "If support for Trickle ICE is confirmed, an agent will automatically > assume support for regular ICE as well even if the support > verification procedure in [rfc5245bis] indicates otherwise." > > What “support verification procedure” are you referring to? Hmm, this might have referred to Section 5.1 of RFC 5245 (which is now gone). In any case, it seems to me that we can safely remove the text "even if the support verification procedure in [rfc5245bis] indicates otherwise." Peter From nobody Thu Jun 8 20:09:11 2017 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35187129408 for ; Thu, 8 Jun 2017 20:09:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=stpeter.im header.b=nuASqG7H; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=m/qZYbFA Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6YsR8tIfH7yl for ; Thu, 8 Jun 2017 20:09:08 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03A10128CDB for ; Thu, 8 Jun 2017 20:09:08 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 5F709208CD; Thu, 8 Jun 2017 23:09:07 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute2.internal (MEProxy); Thu, 08 Jun 2017 23:09:07 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stpeter.im; h= content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=4kpbMsRfF3btjzoXMB kLK0lMIqGxr30xaNNVSXiThJQ=; b=nuASqG7Hp+KJyV2WdfREhm49cOiute9HEp +L7Y0LdWM20CcmFqZPmvrn/oyJlda8Mk18ZJL0hSBDgblYWiNYtWllva+4vHD8O7 m2fZ2qRkEl3PeIb4JAwcSPuV9HgfHyX2Cag3DCgYNUG3MnfPhoWePRFQyhxW5pvT gn5MN8pZK+yGgbW4e2fmkRKZtIKsj3Qam40kXvkNJFPqhHTgaRRZ8FFXGj8U912N K3eFncotqPyeQMbGcvRFmGSXwQe5PUm8Gi1RX0lw9vxx1hrkUenUKfpN/wsBFNso tNEf2dnw2zzL5sstwGP1BD+v8i/X4Tzak/rW1GNmz9qIRxThN2dA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=4kpbMsRfF3btjzoXMBkLK0lMIqGxr30xaNNVSXiThJQ=; b=m/qZYbFA ZZGdBTPWOJsujbtkNt51nWo0D6r+3uA+Qiv3xNDlD5hJJXEPXM9dVgtfkeDRIfej CjJVelC8b3uWw/OBay4TnhlXVNfRY0tjT2Pdu8wphWwGNf06EW4zPb+i058QOmZs VjoYLyHb/vTXUOloKH/oKtWg4333qA7ofHfsUUVpssDzGLo689wqo4sTaXjbKU5/ p2yol+pYqC1OUAw5Bl0SHWgGoWsTWwAfWFX939T9qoyqjwmzodKmQWMo/F4aClsL xrkOejL8BZW9XuZiNjnjQGexTnZ+YWSo1+aY2kcsu1EE7yfrkxOhnUjDtVMTP2Oj yrteNWb9TgY7nQ== X-ME-Sender: X-Sasl-enc: brWsD7vkr5DmBmQQkdptR87qGN7pLhqqUBBamSD1+VBM 1496977747 Received: from aither.local (unknown [76.25.4.24]) by mail.messagingengine.com (Postfix) with ESMTPA id D22EE7E88C; Thu, 8 Jun 2017 23:09:06 -0400 (EDT) To: Christer Holmberg , "ice@ietf.org" References: From: Peter Saint-Andre Message-ID: <26f0f9ba-f125-b8e3-3232-e6f5a8df11d4@stpeter.im> Date: Thu, 8 Jun 2017 21:09:06 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Ice] draft-trickle-11: Comment on sections 5 & 6 X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2017 03:09:09 -0000 On 6/5/17 2:31 AM, Christer Holmberg wrote: > *Section 5 & 6* > * > * > I suggest the main chapter names to be “Responder Procedures” and > “Initiator Procedures”, and then place the sub sections below those. Good idea. > The text mixes between “responder” and “agent” terminology. I > understand that “agent” can be used when describing something that > applies to both “responder” and “initiator”, but the text seems to use > “agent” even when only talking about the responder. We'll try to make that more clear and consistent. Peter From nobody Thu Jun 8 20:22:27 2017 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D352129465 for ; Thu, 8 Jun 2017 20:22:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=stpeter.im header.b=BSpsrK63; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=UuZegU9P Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JTAtN5vc8Yyw for ; Thu, 8 Jun 2017 20:22:23 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DF211242F7 for ; Thu, 8 Jun 2017 20:22:23 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id B3EFE20B60; Thu, 8 Jun 2017 23:22:22 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute2.internal (MEProxy); Thu, 08 Jun 2017 23:22:22 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stpeter.im; h= content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=+8xUnTxXu91mAyS/5w 2Jja2sWJWXhgt/X4Y2Zd03PMA=; b=BSpsrK63vEavkyiENH29GcFIbWcDEGtcAe QK4dPvV/oNOV38Jf8+YLXNJGPInWNMl5dL10SSaMlfQFLB/rTzc4U9BNuxF+gFzB Gmt83gQ549+tQ/aDMXN5o7yZsCjPHAE+yLPyrnDpS8UGf56sA9TzhdZ8YXLFT3Gp UMnh+KdEXaZM+AcNp5yjAMcGeTjtJ9t+RzwojfGehO58l5G0gtDrU7BJxcJKqdZp HK7+RjE/ff0+qQpy3ujBIfNcnnyCF1S/gbZqkDMwiJ/odx4TwSUvh0ySa+mJO4mJ ye8Celvms02/26LeH6QvZRpSlqDWGBaWXV8HHnzlsnU6l9+MIsBQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=+8xUnTxXu91mAyS/5w2Jja2sWJWXhgt/X4Y2Zd03PMA=; b=UuZegU9P t8A3wYCuTfO6ak8KWpoq9BWRGbfrCzZ+lo5ym2R4KKXPwNShv2YSdB4LM4AaLtWj 34x+8NYsatmzS/t8H6XkelhQDfGBWoIg0v3EC86HjGHh+sptTR5GXtwzBxPoJYfJ WGza2tH8W+se1Tyx06TQMF0i2ZJTXnGZ+s5MFBBIdhfaVamb4G3XydXjk6i253WH oWPOFQXACvjlZIu2gv+KtpsWSbSquYEo8pUwPr7Ov1hw3fuHo0UKMGowNHDLqpmS GPIVl8rmYwoiA+ZkQPMvxmZ/qThWUcx93mE3iU/VuwtD4LhFr2urF5UvYbtwmAQR jzEiH1t6Fu+LyQ== X-ME-Sender: X-Sasl-enc: gtxdrRD7mTT7gZGeIkHMovo7eyjVaSYQJLAaX1RH+8wH 1496978542 Received: from aither.local (unknown [76.25.4.24]) by mail.messagingengine.com (Postfix) with ESMTPA id 2AA812475E; Thu, 8 Jun 2017 23:22:22 -0400 (EDT) To: Christer Holmberg , Thomas Stach , "ice@ietf.org" References: From: Peter Saint-Andre Message-ID: Date: Thu, 8 Jun 2017 21:22:21 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Ice] draft-trickle-11: Comment on section 15 X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2017 03:22:25 -0000 There are two delivery "levels" here: (a) signaling-layer transport of a particular message (such as a SIP INFO request or XMPP IQ stanza), which could include information about one or more candidates (b) semantic communication of a candidate, potentially across multiple messages (as in the example from draft-ietf-mmusic-trickle-ice-sip) As I understand it, this text in the trickle spec was meant to address (a), not (b). If we're talking about (a), then do people have concerns with specifying that the signaling protocol needs to ensure in-order delivery and "at most once" delivery? (Note that this could include things like acks and retries as necessary in order to ensure delivery.) If we're talking about (b), then we'd probably want to specify that the signaling protocol needs to send each candidate "at least once", and that endpoints need to detect duplicates. Peter On 6/6/17 12:45 AM, Christer Holmberg wrote: > Hi Thomas, > > The fact that the receiver discards the candidates doesn¹t change the fact > that they are *delivered* using the signaling protocol (SIP INFO). > > So, rather than talking about the singling protocol, perhaps the > requirement should be that endpoint need to be able to detect repeated > candidates? > > Regards, > > Christer > > > On 05/06/17 22:59, "Ice on behalf of Thomas Stach" on behalf of thomass.stach@gmail.com> wrote: > >> Christer, >> >> >> On 2017-06-05 10:34, Christer Holmberg wrote: >>> *Section 15* >>> * >>> * >>> The text says: >>> o A signaling protocol MUST deliver each trickled candidate not more >>> than once and in the same order it was conveyed (see Section 8). >>> >>> - I think you should use MUST NOT deliver more than once terminology. >>> ³MUST Š not more than² sounds strange. >>> >>> - This may belong to MMUSIC, but draft-music-trickle-ice-sip defines >>> that each each SIP INFO request (used to carry trickled candidates) >>> contains all known candidates - including previously trickled ones. Is >>> that aligned with the requirement above? >> The actual text in section 4.2 of draft-music-trickle-ice-sip is as >> follows, >> with "agent" meaning a SIP UA and "ICE agent" meaning the entity that >> actually deals with ICE: >> >> Since the agent is not fully aware of the state of the ICE >> Negotiation Session at its peer it MUST include all currently known >> and used local candidates in every INFO request. I.e. all candidates >> that were previously sent under the same combination of "a=ice-pwd:" >> and "a=ice-ufrag:" need to be repeated. Although repeating all >> candidates creates some overhead, it also allows easier handling of >> problems that could arise from unreliable transports, like e.g. loss >> of messages and reordering, which can be detected through the CSeq: >> header field in the INFO request. >> >> When receiving INFO requests carrying any candidates, agents will >> therefore first identify and discard the attribute lines containing >> candidates they have already received in previous INFO requests or in >> the Offer/Answer exchange preceding them. Two candidates are >> considered to be equal if their IP address port, transport and >> component ID are the same. After identifying and discarding known >> candidates, the ICE agents will then process the remaining, actually >> new candidates according to the rules described in >> [I-D.ietf-ice-trickle >> > ietf-ice-trickle>]. >> >> So, the requirement is covered by the second paragraph. >> >> Regards >> Thomas >> >>> >>> Regards, >>> >>> Christer >>> >>> From nobody Thu Jun 8 20:24:03 2017 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DEC31294CD for ; Thu, 8 Jun 2017 20:24:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=stpeter.im header.b=Cw1sHFeu; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=ApCwgcd9 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QR4g4Cf7kzPR for ; Thu, 8 Jun 2017 20:24:00 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3793112947D for ; Thu, 8 Jun 2017 20:24:00 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 9D819209D3; Thu, 8 Jun 2017 23:23:59 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute2.internal (MEProxy); Thu, 08 Jun 2017 23:23:59 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stpeter.im; h= content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=AiGUVjO2aSPjhOfsoc nlfvM6+BRPosm6h14I84EHPsI=; b=Cw1sHFeuonuaFKZzXIZVprlzg1yfsJ9OAe zq4Jo5MSm3BxUjj3a+4CVIj2DeXzBGYopZcNZVqs1f63IEcINyMcOVxgOvdept2P id8d2cUmRAFr64kHEMOk3tjh94nhvmuzMaYK6kYvBIgZA39+nPbuNqCQXg6n8+wG RKDj8LyNuI2jIi9UOXz7bEBkx2Fgg9R7HLKO8wdN0gH1vKwKTvXiywKQwxVG6E4X TSzJDVAYc3lMpPjejYqvysNdqFmFbCl8524rKi1cPxQcZmqg2tS/ExiWxGgpWTmB mUJVQl3JNhyYcXEI7EQyYt8UBy6CPDEAbk69cCQD6f8pjTvPSlMw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=AiGUVjO2aSPjhOfsocnlfvM6+BRPosm6h14I84EHPsI=; b=ApCwgcd9 Ccp8e9OoXcUKa4zWl2GUKjvEYScrHRrXREv6W0MZx4TjkKBMZmWJW8PBFj3FJ+s3 3wDG2iac8FrxZ49t1ObzOmJue+Xf/Gfx3A84UYSyEK790dWzlpimQwP/iUL/vPYJ oAZbL2Fftj0ppTiRjYj9DM72MNCHc2mKWgKAp4hBoPPgBkmgOvE+8YCDmU/O3Ee6 KDrkWa8C993g/ppypFZG19Mxpt+Wsiirrwnhl9CQRnnJQrGIflhUZjuTwc+GYFfP d07aYCycFVoL5qdYJqtAHI12bgwlUQ/encFk8acgPYKrT/Rf6s099Kmkg8gsiC5D 9wpFzSO5fo2jFQ== X-ME-Sender: X-Sasl-enc: AUm48DGsXYRRGWkg9qW+v68T2S5ORjEhDUFOgDzAV0up 1496978639 Received: from aither.local (unknown [76.25.4.24]) by mail.messagingengine.com (Postfix) with ESMTPA id 11D7F248E2; Thu, 8 Jun 2017 23:23:59 -0400 (EDT) To: Peter Thatcher , Christer Holmberg , "ice@ietf.org" References: From: Peter Saint-Andre Message-ID: Date: Thu, 8 Jun 2017 21:23:58 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Ice] trickle-11: Unfreezing of candidate pairs on connectivity check success X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2017 03:24:02 -0000 On 6/1/17 6:35 PM, Peter Thatcher wrote: > Ah, you are right. That seems wrong to me. Agreed. > But I'd like it if > Emil can double check. I'll look, too (and double-check the figures while I'm at it). > > On Wed, May 31, 2017 at 11:49 PM Christer Holmberg > > wrote: > > Hi, > >> I'm a little confused about the second point. It seems like the >> text is saying to unfreeze the pairs with the same foundation in >> all check lists, and that sounds correct to me. > > That is what it should say :) > > But the text says “for the SAME media stream and foundation”. It > should say “for ALL media streams with the same foundation”. > > Also, in Figure 3 only m2 is set to W. m3 and m4 should also be set > to W. > > Now, in Figure 4 m3 and m4 ARE set to W, so maybe my issue is that I > don’t really see the difference between Figure 3 and 4. Couldn't > Figure 3 be removed? > > Regards, > > Christer > > > > > > > > > On Mon, May 29, 2017 at 5:17 AM Christer Holmberg > > wrote: > > Hi, > > We may have discussed this before, but as it still exists in > draft-trickle-11 I will comment on it: > > Section 8.1.1. contains the following text: > > "Then, as the checks proceed (see Section 6.2.5.4 of [rfc5245bis]), > for each pair that enters the Succeeded state (denoted here by "S"), > the agent will unfreeze all pairs for the same media stream and > foundation (e.g., if the pair in column 1, row 1 succeeds then the > agent will unfreeze the pair in column 1, row 2).² > > > First, I believe the 5245bis section to reference is 6.2.5.3.3. > > Second, according to the text in section 6.2.5.3.3 of 5245bis, *all* > pairs for *all* streams (for a given foundation) are unfrozen once > the checked pair succeeds - not only pairs for the same stream. > > "The success of the connectivity check might also cause the state of > other candidate pairs to change. The ICE agent MUST set the states > for all other Frozen candidate pairs (in each CHECK LIST in the > CHECK LIST SET) with the same foundation to Waiting." > > > Regards, > > Christer > > _______________________________________________ Ice mailing list > Ice@ietf.org > https://www.ietf.org/mailman/listinfo/ice > > > > _______________________________________________ Ice mailing list > Ice@ietf.org https://www.ietf.org/mailman/listinfo/ice > From nobody Sun Jun 11 16:25:55 2017 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F194129AD5 for ; Sun, 11 Jun 2017 16:25:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=stpeter.im header.b=FkpQEcMB; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=TNoZblaM Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cpxy1VyF1m_J for ; Sun, 11 Jun 2017 16:25:51 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85920129463 for ; Sun, 11 Jun 2017 16:25:51 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id E331520818; Sun, 11 Jun 2017 19:25:50 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute2.internal (MEProxy); Sun, 11 Jun 2017 19:25:50 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stpeter.im; h= content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=xqHWb9L4Es8fOTcSOc XpNAPNTB0ZMCMHwXAsxs/Mbrs=; b=FkpQEcMB5XGBSjQrHq0E1diwc55NpC+gI4 aJryuFVVEQWrzTWVW6s1CiioI6idrV9HsckZuZb4FMvmy1l9T0Kdotpg35BshD70 dGP4ta8n0ChUtLkkGdzwhgiwhXi0ZsrOWba3cLiYWssrVcELdHFndTBB4NGDDtkV 9Dcnu6kknKQo4qegq4LZ1eMPh9Icxl6541iazczG16buH+Bgv/3Eup9HkJuLN6Bl iEDRBganSj4JxT9WBVLGGODQ0Q7EmgfEdunkLIlpcjN0l529XHrZZZx53ZeGBzGx mrpADE6tsYscX58tgJtNeAmM0mOKG87CTtO2BsA1yFx2hvqQQcUQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=xqHWb9L4Es8fOTcSOcXpNAPNTB0ZMCMHwXAsxs/Mbrs=; b=TNoZblaM vCzsP2JNAJqGWMAJqPAuZZIrDMLTg50Egi4i3W0ghpdpNmnBsErM82XaZ1PZms4q BFaLZrQwF27Tlo0S06g8xeRWsLJKHlHSKfdmglFK0ARkcal5BdR38mMbdj7jbUIQ T3BWCNpGCrhSTSxcoOeqCINZknRCtzSE0e+uvh1uLVP3u3AWuu91hsvJtkZqOgOK BPf1gWopiigXIKvw1jCMPLsFjcTnf7B1sJBHI29Or0SPIHIzLJ797HTm0Q3UrwmZ gYvXrQZYNVeBU25V6f8pp5jBQc7v3xJMWeBKxjlWCfRWSCzAIK9+SUJqPDltFP8n bZfFrK6McnyFzA== X-ME-Sender: X-Sasl-enc: GN3pLw8uoJCeofiT/GGm2vR/4uwNsqXyjjrLM/hHDtkd 1497223550 Received: from aither.local (unknown [76.25.4.24]) by mail.messagingengine.com (Postfix) with ESMTPA id 416DF247E8; Sun, 11 Jun 2017 19:25:50 -0400 (EDT) To: Christer Holmberg , Peter Thatcher , "ice@ietf.org" References: From: Peter Saint-Andre Message-ID: <3e5dfcce-3f05-c2d3-20f2-9501d6312d0d@stpeter.im> Date: Sun, 11 Jun 2017 17:25:48 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Ice] trickle-11: Unfreezing of candidate pairs on connectivity check success X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jun 2017 23:25:54 -0000 On 6/1/17 12:48 AM, Christer Holmberg wrote: > Hi, > >> I'm a little confused about the second point. It seems like the text is saying to unfreeze the pairs with the same foundation in all check lists, and that sounds correct to me. > > That is what it should say :) > > But the text says “for the SAME media stream and foundation”. It should > say “for ALL media streams with the same foundation”. I agree that this seems correct. > Also, in Figure 3 only m2 is set to W. m3 and m4 should also be set to W. > > Now, in Figure 4 m3 and m4 ARE set to W, so maybe my issue is that I > don’t really see the difference between Figure 3 and 4. Couldn't Figure > 3 be removed? Yes, it can. Consider it done (unless Emil objects). Peter From nobody Wed Jun 14 20:46:52 2017 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8130E12943C for ; Wed, 14 Jun 2017 20:46:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=stpeter.im header.b=CatBXI2/; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=DKkjutFr Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oIPm4_vwPXm1 for ; Wed, 14 Jun 2017 20:46:49 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E9361242F5 for ; Wed, 14 Jun 2017 20:46:49 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 9C72F208A0; Wed, 14 Jun 2017 23:46:48 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute2.internal (MEProxy); Wed, 14 Jun 2017 23:46:48 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stpeter.im; h= content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=g6u1mwmZbhQS78HsLV NqDHVSdPICpc8VGxErfYtHQZs=; b=CatBXI2/bpdYacC5iaEFB0aMDtSOdUBe92 59wC18t/hZ4ol0eFKXQKks5PAGzFo7ddJ79aL1WHIBLs9syh5Ph4y6ViWpJt3Vz5 6aD71qwvrc0g1lfR3ZRLY9vmS4nBT6IwZSudlDr+G7aQTdrLLeg61S7HGLH8iqYj ubjEhBvNH69/ioMQbzG+XjZjb4VxdUVYaBYw/0Dbm9b2kQ4O3f5KEhFZ9BjbCJc8 vGzIT+xlxhUEkpoHz0t8alX41YT6ItbRqvpFCdCxFp4afA3z7/07Gb9k9cYmVl9f S0p1UuGCBl7ULFhXnSppHPZbSlAlhm7Fhs/3vByVp0/K9LkjS3Sw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=g6u1mwmZbhQS78HsLVNqDHVSdPICpc8VGxErfYtHQZs=; b=DKkjutFr pIMoWCQDr0kEF/axqKuSQUjLbznizR3jbusKcXsUz4dbHRvg16Qyf7k9LBIGH5be Z4S699qcLD5+hk2yx437+ZhZp6rG8fVNZQ0JFwl+RS1Up8dgLIsFAqK1NukO7Nlv CS6E06hSdPt228bOLkda1+oAzVfJ4IMiMWWXLwKZVIb9jlP7jZ7jUJccHW5sCzli B1fOcbdueaFHr7BGBDCBH3RDyhHSzD/dSkVibIZufSjfxE4y10tBenN0nARazj3Q 8xqkqLvZ0Kk6RgchKlA3qUryH/DbrBaljNxGSKBz2ENxKk0MQCc6Zty13RHTnxiQ RTT2aadCINZBSA== X-ME-Sender: X-Sasl-enc: qzYFpIiWrKjWwUemAHeDaCbWYpHClpmMmRNLYPL8gy0a 1497498408 Received: from aither.local (unknown [76.25.4.24]) by mail.messagingengine.com (Postfix) with ESMTPA id 0EDB57E800; Wed, 14 Jun 2017 23:46:47 -0400 (EDT) To: Christer Holmberg , Thomas Stach , "ice@ietf.org" References: From: Peter Saint-Andre Message-ID: <2beef248-4046-927a-fd3b-3be5a6072b8a@stpeter.im> Date: Wed, 14 Jun 2017 21:46:45 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Ice] draft-trickle-11: Comment on section 15 X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2017 03:46:51 -0000 Does anyone have further input / insights on this topic? If not, I will propose some textual clarifications. On 6/8/17 9:22 PM, Peter Saint-Andre wrote: > There are two delivery "levels" here: > > (a) signaling-layer transport of a particular message (such as a SIP > INFO request or XMPP IQ stanza), which could include information about > one or more candidates > > (b) semantic communication of a candidate, potentially across multiple > messages (as in the example from draft-ietf-mmusic-trickle-ice-sip) > > As I understand it, this text in the trickle spec was meant to address > (a), not (b). > > If we're talking about (a), then do people have concerns with specifying > that the signaling protocol needs to ensure in-order delivery and "at > most once" delivery? (Note that this could include things like acks and > retries as necessary in order to ensure delivery.) > > If we're talking about (b), then we'd probably want to specify that the > signaling protocol needs to send each candidate "at least once", and > that endpoints need to detect duplicates. > > Peter > > On 6/6/17 12:45 AM, Christer Holmberg wrote: >> Hi Thomas, >> >> The fact that the receiver discards the candidates doesn¹t change the fact >> that they are *delivered* using the signaling protocol (SIP INFO). >> >> So, rather than talking about the singling protocol, perhaps the >> requirement should be that endpoint need to be able to detect repeated >> candidates? >> >> Regards, >> >> Christer >> >> >> On 05/06/17 22:59, "Ice on behalf of Thomas Stach" > on behalf of thomass.stach@gmail.com> wrote: >> >>> Christer, >>> >>> >>> On 2017-06-05 10:34, Christer Holmberg wrote: >>>> *Section 15* >>>> * >>>> * >>>> The text says: >>>> o A signaling protocol MUST deliver each trickled candidate not more >>>> than once and in the same order it was conveyed (see Section 8). >>>> >>>> - I think you should use MUST NOT deliver more than once terminology. >>>> ³MUST Š not more than² sounds strange. >>>> >>>> - This may belong to MMUSIC, but draft-music-trickle-ice-sip defines >>>> that each each SIP INFO request (used to carry trickled candidates) >>>> contains all known candidates - including previously trickled ones. Is >>>> that aligned with the requirement above? >>> The actual text in section 4.2 of draft-music-trickle-ice-sip is as >>> follows, >>> with "agent" meaning a SIP UA and "ICE agent" meaning the entity that >>> actually deals with ICE: >>> >>> Since the agent is not fully aware of the state of the ICE >>> Negotiation Session at its peer it MUST include all currently known >>> and used local candidates in every INFO request. I.e. all candidates >>> that were previously sent under the same combination of "a=ice-pwd:" >>> and "a=ice-ufrag:" need to be repeated. Although repeating all >>> candidates creates some overhead, it also allows easier handling of >>> problems that could arise from unreliable transports, like e.g. loss >>> of messages and reordering, which can be detected through the CSeq: >>> header field in the INFO request. >>> >>> When receiving INFO requests carrying any candidates, agents will >>> therefore first identify and discard the attribute lines containing >>> candidates they have already received in previous INFO requests or in >>> the Offer/Answer exchange preceding them. Two candidates are >>> considered to be equal if their IP address port, transport and >>> component ID are the same. After identifying and discarding known >>> candidates, the ICE agents will then process the remaining, actually >>> new candidates according to the rules described in >>> [I-D.ietf-ice-trickle >>> >> ietf-ice-trickle>]. >>> >>> So, the requirement is covered by the second paragraph. >>> >>> Regards >>> Thomas >>> >>>> >>>> Regards, >>>> >>>> Christer >>>> >>>> > From nobody Wed Jun 14 20:47:34 2017 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D819B12943C for ; Wed, 14 Jun 2017 20:47:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=stpeter.im header.b=K42rancn; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=TXOvmbD3 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wv-xbFD67n-s for ; Wed, 14 Jun 2017 20:47:31 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE3D6127180 for ; Wed, 14 Jun 2017 20:47:31 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 2457A208A5; Wed, 14 Jun 2017 23:47:31 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute2.internal (MEProxy); Wed, 14 Jun 2017 23:47:31 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stpeter.im; h= content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=Igzg3r2dGzTlGKGR78 oqHODOxAeConppJ/AMcRC/wrQ=; b=K42rancnb2EPptOdqJjAwzboIs1IriDw7q JWQ03JT29ZUiHVkiWfjb8+GxVddcbBqvC8DHFewKz4q80iUgBUriGBWiejd4hVbg Sd5zuu8gnFneUC7GeVteIoHfuFSCyJvjkJgCLUpAeJZwmNMuZfnenfXabXdtXx8x pQgDI/8EJEhe/roeSCTsSatWejMwZ4+QrqVDXfs0g5SOYLbkMS2RpcXV6yw8aIXQ BZJrPc/BWiHdGVNNBx0vP5nzhUEwuk5YbX80ZSw7qNEbZQdOnzf0zNydh4DtFY1X ldIrhPsPKL3Nu08lioKRtl4EHC31w4A76vYDKzz+nIvPAh9ykznA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=Igzg3r2dGzTlGKGR78oqHODOxAeConppJ/AMcRC/wrQ=; b=TXOvmbD3 EoDmvUeOvTQH024KFjOcnLo0keHAjwaEx/Pcw7Bw3ReatkoVcYpnxhie+KLis/Yj K8iBGyhu7UATRGxLX2QSHX4XIONHYHz2OQ1/cxG7sgmon772wrUMIqjF5NKp68+a 1wHB83e3L+TPftP6qHH3Buh5WlHgcqFsjpqBYEe6STIq0zI6VzlZbtLdLwobJM5t aLytKGErW07FEPZQJa4jHIirGOsLCU0G5LWVrGfUaFSPNRRQGZaiW822bjrOnEMp ZV7r7ePo+5RhxAJpEV1TRLlIkS5Wabxocp3PvERRVnDXT+Iq33F393T72Ww4yFJr y7V2WFvgewB4Ag== X-ME-Sender: X-Sasl-enc: 9mH4Cr2A9dzlRkI2N6+GqJwG5fDXSa5OpLjazjOd7C6d 1497498450 Received: from aither.local (unknown [76.25.4.24]) by mail.messagingengine.com (Postfix) with ESMTPA id 9D4987E865; Wed, 14 Jun 2017 23:47:30 -0400 (EDT) To: Christer Holmberg , "ice@ietf.org" References: <0b357375-8759-ee20-9ca5-a473ffa92cb0@stpeter.im> From: Peter Saint-Andre Message-ID: <91457c18-f6a7-c496-c0e8-5af5c4d2188e@stpeter.im> Date: Wed, 14 Jun 2017 21:47:29 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <0b357375-8759-ee20-9ca5-a473ffa92cb0@stpeter.im> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Ice] draft-trickle-11: Comment on section 3 X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2017 03:47:33 -0000 Christer, is this clear or would you like me to improve the text? On 6/8/17 8:59 PM, Peter Saint-Andre wrote: > On 6/5/17 2:30 AM, Christer Holmberg wrote: >> *Section 3* >> >> The text says: >> >> "If an agent determines that the remote party does not support Trickle ICE, it >> MUST fall back to using regular ICE or abandon the entire session." >> >> This is confusing, because earlier the draft says that half trickle can >> be used if the remote party doesn’t support trickle. > > Section 2 states: > > The [half trickle] > mechanism is mostly meant for use in cases where the remote > agent's support for Trickle ICE cannot be confirmed prior to > conveying the initial ICE parameters. > > Not being able to determine the remote agent's support for trickle is > different from definitively determining that the remote agent does not > support trickle (the case covered by the text in Section 3). > > If this is not sufficiently clear, we can improve the text. > >> And, I don’t think >> “regular ICE” and “half trickle” are the same things, are they? > > I don't think the spec implies that they are. > > Peter > > From nobody Wed Jun 14 23:20:44 2017 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A67E129B0D for ; Wed, 14 Jun 2017 23:20:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 RKWyxMiRxQTq for ; Wed, 14 Jun 2017 23:20:40 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CF24129AF9 for ; Wed, 14 Jun 2017 23:20:39 -0700 (PDT) X-AuditID: c1b4fb30-4a9ff70000003fda-e3-5942273640be Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.183.36]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id A9.44.16346.63722495; Thu, 15 Jun 2017 08:20:38 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.30]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.03.0339.000; Thu, 15 Jun 2017 08:20:38 +0200 From: Christer Holmberg To: Peter Saint-Andre , Thomas Stach , "ice@ietf.org" Thread-Topic: [Ice] draft-trickle-11: Comment on section 15 Thread-Index: AQHS3dZ/cBKgt2WVVE+FUUPx8uxmV6IWj0eAgADorQCABEoNgIAJdM+AgABfOQA= Date: Thu, 15 Jun 2017 06:20:37 +0000 Message-ID: References: <2beef248-4046-927a-fd3b-3be5a6072b8a@stpeter.im> In-Reply-To: <2beef248-4046-927a-fd3b-3be5a6072b8a@stpeter.im> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.4.170508 x-originating-ip: [153.88.183.146] Content-Type: text/plain; charset="utf-8" Content-ID: <28C916185320C548A74BDA416833A36F@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprNIsWRmVeSWpSXmKPExsUyM2K7iq6ZulOkwfpPEhbfLtRaHNvTz2zx 6cRWJgdmj52z7rJ7LFnyk8lj7p4XzAHMUVw2Kak5mWWpRfp2CVwZu45vZSr4Z1Cx88od1gbG O/pdjJwcEgImEl/ff2HsYuTiEBI4wigx6eFXNghnMaPEhef97F2MHBxsAhYS3f+0QRpEBIol 1vyezQRiCwtYSbRNXcQIEbeW2PjgNAuE7SfRv+ApWJxFQFVi6eLZYHFeoJqH5+ewQMzvYJL4 dvIKK0iCU8BO4kHXKTYQm1FATOL7qTVgC5gFxCVuPZnPBHGpgMSSPeeZIWxRiZeP/7GC3CYq oCfxbr8nRFhJ4seGSywgYWYBTYn1u/QhplhLrFrTwQ5hK0pM6X7IDnGOoMTJmU9YJjCKzUKy bBZC9ywk3bOQdM9C0r2AkXUVo2hxanFSbrqRkV5qUWZycXF+nl5easkmRmCUHdzy22AH48vn jocYBTgYlXh4mZmdIoVYE8uKK3MPMUpwMCuJ8NoqAIV4UxIrq1KL8uOLSnNSiw8xSnOwKInz Ou67ECEkkJ5YkpqdmlqQWgSTZeLglGpg5OzY+uhq8sIzT/fuUk5i7zgYNHeN0tE3VTKPH1ql rHLPYWMst2mYozR5f0llid2D2B1Ozjf3nnnC0dzMll/+5KOweofBhP3v6/9zPZAPbfzN31yf vqkoavoVT83zoQX/RFJcLXp/Jk/rsrwXKsnGH7DUYz9jQfbxe3+adl5Z0ybxq0/gv+x1JZbi jERDLeai4kQAUMHGm64CAAA= Archived-At: Subject: Re: [Ice] draft-trickle-11: Comment on section 15 X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2017 06:20:42 -0000 DQpIaSwNCg0KSSB3YXMgd3JpdGluZyBhIHJlcGx5IGVhcmxpZXIsIGJ1dCByZWFsaXNlZCBpdCBn b3Qgc3R1Y2tlZCBpbiBteSBEcmFmdHMNCmZvbGRlci4NCg0KQmVmb3JlIHlvdSBzdWdnZXN0IHRl eHQsIEkgaGF2ZSBhIGNvdXBsZSBvZiBxdWVzdGlvbnMgb24gUGV0ZXLigJlzIGVhcmxpZXINCnJl cGx5Lg0KDQo+PlRoZXJlIGFyZSB0d28gZGVsaXZlcnkgImxldmVscyIgaGVyZToNCj4+IA0KPj4g KGEpIHNpZ25hbGluZy1sYXllciB0cmFuc3BvcnQgb2YgYSBwYXJ0aWN1bGFyIG1lc3NhZ2UgKHN1 Y2ggYXMgYSBTSVANCj4+IElORk8gcmVxdWVzdCBvciBYTVBQIElRIHN0YW56YSksIHdoaWNoIGNv dWxkIGluY2x1ZGUgaW5mb3JtYXRpb24gYWJvdXQNCj4+IG9uZSBvciBtb3JlIGNhbmRpZGF0ZXMN Cj4+IA0KPj4gKGIpIHNlbWFudGljIGNvbW11bmljYXRpb24gb2YgYSBjYW5kaWRhdGUsIHBvdGVu dGlhbGx5IGFjcm9zcyBtdWx0aXBsZQ0KPj4gbWVzc2FnZXMgKGFzIGluIHRoZSBleGFtcGxlIGZy b20gZHJhZnQtaWV0Zi1tbXVzaWMtdHJpY2tsZS1pY2Utc2lwKQ0KPj4gDQo+PiBBcyBJIHVuZGVy c3RhbmQgaXQsIHRoaXMgdGV4dCBpbiB0aGUgdHJpY2tsZSBzcGVjIHdhcyBtZWFudCB0byBhZGRy ZXNzDQo+PiAoYSksIG5vdCAoYikuDQo+PklmIHdlJ3JlIHRhbGtpbmcgYWJvdXQgKGEpLCB0aGVu IGRvIHBlb3BsZSBoYXZlIGNvbmNlcm5zIHdpdGggc3BlY2lmeWluZw0KPj4gdGhhdCB0aGUgc2ln bmFsaW5nIHByb3RvY29sIG5lZWRzIHRvIGVuc3VyZSBpbi1vcmRlciBkZWxpdmVyeSBhbmQgImF0 DQo+PiBtb3N0IG9uY2UiIGRlbGl2ZXJ5PyAoTm90ZSB0aGF0IHRoaXMgY291bGQgaW5jbHVkZSB0 aGluZ3MgbGlrZSBhY2tzIGFuZA0KPj4gcmV0cmllcyBhcyBuZWNlc3NhcnkgaW4gb3JkZXIgdG8g ZW5zdXJlIGRlbGl2ZXJ5LikNCg0KSSBhbSBub3Qgc3VyZSB3aGV0aGVyIHdlIG5lZWQgdG8gc2F5 IOKAnGF0IG1vc3Qgb25jZeKAnS4gSXNu4oCZdCBpcyBlbm91Z2ggdG8NCnNheSDigJxlbnN1cmUg ZGVsaXZlcnnigJ0/DQoNCldoeSBkbyB3ZSBuZWVkIHRvIHJlcXVpcmUgaW4tb3JkZXIgZGVsaXZl cnk/DQoNCj4+IA0KPj4gSWYgd2UncmUgdGFsa2luZyBhYm91dCAoYiksIHRoZW4gd2UnZCBwcm9i YWJseSB3YW50IHRvIHNwZWNpZnkgdGhhdCB0aGUNCj4+IHNpZ25hbGluZyBwcm90b2NvbCBuZWVk cyB0byBzZW5kIGVhY2ggY2FuZGlkYXRlICJhdCBsZWFzdCBvbmNlIiwgYW5kDQo+PiB0aGF0IGVu ZHBvaW50cyBuZWVkIHRvIGRldGVjdCBkdXBsaWNhdGVzLg0KDQpJIHRoaW5rIHdlIGNvdWxkIHNh eSB0aGF0IHRoZSBzaWduYWxsaW5nIHByb3RvY29sIG5lZWRzIHRvIHByb3ZpZGUgYQ0KbWVjaGFu aXNtIGZvciB0aGUgYXBwbGljYXRpb24gdG8gZGV0ZWN0IGR1cGxpY2F0ZXMuDQoNClJlZ2FyZHMs DQoNCkNocmlzdGVyDQoNCg0KDQoNCg0KPj4gDQo+PiBQZXRlcg0KPj4gDQo+PiBPbiA2LzYvMTcg MTI6NDUgQU0sIENocmlzdGVyIEhvbG1iZXJnIHdyb3RlOg0KPj4+IEhpIFRob21hcywNCj4+Pg0K Pj4+IFRoZSBmYWN0IHRoYXQgdGhlIHJlY2VpdmVyIGRpc2NhcmRzIHRoZSBjYW5kaWRhdGVzIGRv ZXNuwrl0IGNoYW5nZSB0aGUNCj4+PmZhY3QNCj4+PiB0aGF0IHRoZXkgYXJlICpkZWxpdmVyZWQq IHVzaW5nIHRoZSBzaWduYWxpbmcgcHJvdG9jb2wgKFNJUCBJTkZPKS4NCj4+Pg0KPj4+IFNvLCBy YXRoZXIgdGhhbiB0YWxraW5nIGFib3V0IHRoZSBzaW5nbGluZyBwcm90b2NvbCwgcGVyaGFwcyB0 aGUNCj4+PiByZXF1aXJlbWVudCBzaG91bGQgYmUgdGhhdCBlbmRwb2ludCBuZWVkIHRvIGJlIGFi bGUgdG8gZGV0ZWN0IHJlcGVhdGVkDQo+Pj4gY2FuZGlkYXRlcz8NCj4+Pg0KPj4+IFJlZ2FyZHMs DQo+Pj4NCj4+PiBDaHJpc3Rlcg0KPj4+DQo+Pj4NCj4+PiBPbiAwNS8wNi8xNyAyMjo1OSwgIklj ZSBvbiBiZWhhbGYgb2YgVGhvbWFzIFN0YWNoIg0KPj4+PGljZS1ib3VuY2VzQGlldGYub3JnDQo+ Pj4gb24gYmVoYWxmIG9mIHRob21hc3Muc3RhY2hAZ21haWwuY29tPiB3cm90ZToNCj4+Pg0KPj4+ PiBDaHJpc3RlciwNCj4+Pj4NCj4+Pj4NCj4+Pj4gT24gMjAxNy0wNi0wNSAxMDozNCwgQ2hyaXN0 ZXIgSG9sbWJlcmcgd3JvdGU6DQo+Pj4+PiAqU2VjdGlvbiAxNSoNCj4+Pj4+ICoNCj4+Pj4+ICoN Cj4+Pj4+IFRoZSB0ZXh0IHNheXM6DQo+Pj4+PiAgIG8gIEEgc2lnbmFsaW5nIHByb3RvY29sIE1V U1QgZGVsaXZlciBlYWNoIHRyaWNrbGVkIGNhbmRpZGF0ZSBub3QNCj4+Pj4+bW9yZQ0KPj4+Pj4g ICAgICAgIHRoYW4gb25jZSBhbmQgaW4gdGhlIHNhbWUgb3JkZXIgaXQgd2FzIGNvbnZleWVkIChz ZWUgU2VjdGlvbg0KPj4+Pj44KS4NCj4+Pj4+DQo+Pj4+PiAtIEkgdGhpbmsgeW91IHNob3VsZCB1 c2UgTVVTVCBOT1QgZGVsaXZlciBtb3JlIHRoYW4gb25jZSB0ZXJtaW5vbG9neS4NCj4+Pj4+IMKz TVVTVCDFoCBub3QgbW9yZSB0aGFuwrIgc291bmRzIHN0cmFuZ2UuDQo+Pj4+Pg0KPj4+Pj4gLSBU aGlzIG1heSBiZWxvbmcgdG8gTU1VU0lDLCBidXQgZHJhZnQtbXVzaWMtdHJpY2tsZS1pY2Utc2lw IGRlZmluZXMNCj4+Pj4+IHRoYXQgZWFjaCBlYWNoIFNJUCBJTkZPIHJlcXVlc3QgKHVzZWQgdG8g Y2FycnkgdHJpY2tsZWQgY2FuZGlkYXRlcykNCj4+Pj4+IGNvbnRhaW5zIGFsbCBrbm93biBjYW5k aWRhdGVzIC0gaW5jbHVkaW5nIHByZXZpb3VzbHkgdHJpY2tsZWQgb25lcy4NCj4+Pj4+SXMNCj4+ Pj4+IHRoYXQgYWxpZ25lZCB3aXRoIHRoZSByZXF1aXJlbWVudCBhYm92ZT8NCj4+Pj4gVGhlIGFj dHVhbCAgdGV4dCBpbiBzZWN0aW9uIDQuMiBvZiBkcmFmdC1tdXNpYy10cmlja2xlLWljZS1zaXAg aXMgYXMNCj4+Pj4gZm9sbG93cywNCj4+Pj4gd2l0aCAiYWdlbnQiIG1lYW5pbmcgYSBTSVAgVUEg YW5kICJJQ0UgYWdlbnQiIG1lYW5pbmcgdGhlIGVudGl0eSB0aGF0DQo+Pj4+IGFjdHVhbGx5IGRl YWxzIHdpdGggSUNFOg0KPj4+Pg0KPj4+PiAgICBTaW5jZSB0aGUgYWdlbnQgaXMgbm90IGZ1bGx5 IGF3YXJlIG9mIHRoZSBzdGF0ZSBvZiB0aGUgSUNFDQo+Pj4+ICAgIE5lZ290aWF0aW9uIFNlc3Np b24gYXQgaXRzIHBlZXIgaXQgTVVTVCBpbmNsdWRlIGFsbCBjdXJyZW50bHkga25vd24NCj4+Pj4g ICAgYW5kIHVzZWQgbG9jYWwgY2FuZGlkYXRlcyBpbiBldmVyeSBJTkZPIHJlcXVlc3QuICBJLmUu IGFsbA0KPj4+PmNhbmRpZGF0ZXMNCj4+Pj4gICAgdGhhdCB3ZXJlIHByZXZpb3VzbHkgc2VudCB1 bmRlciB0aGUgc2FtZSBjb21iaW5hdGlvbiBvZg0KPj4+PiJhPWljZS1wd2Q6Ig0KPj4+PiAgICBh bmQgImE9aWNlLXVmcmFnOiIgbmVlZCB0byBiZSByZXBlYXRlZC4gIEFsdGhvdWdoIHJlcGVhdGlu ZyBhbGwNCj4+Pj4gICAgY2FuZGlkYXRlcyBjcmVhdGVzIHNvbWUgb3ZlcmhlYWQsIGl0IGFsc28g YWxsb3dzIGVhc2llciBoYW5kbGluZyBvZg0KPj4+PiAgICBwcm9ibGVtcyB0aGF0IGNvdWxkIGFy aXNlIGZyb20gdW5yZWxpYWJsZSB0cmFuc3BvcnRzLCBsaWtlIGUuZy4NCj4+Pj5sb3NzDQo+Pj4+ ICAgIG9mIG1lc3NhZ2VzIGFuZCByZW9yZGVyaW5nLCB3aGljaCBjYW4gYmUgZGV0ZWN0ZWQgdGhy b3VnaCB0aGUgQ1NlcToNCj4+Pj4gICAgaGVhZGVyIGZpZWxkIGluIHRoZSBJTkZPIHJlcXVlc3Qu DQo+Pj4+DQo+Pj4+ICAgIFdoZW4gcmVjZWl2aW5nIElORk8gcmVxdWVzdHMgY2FycnlpbmcgYW55 IGNhbmRpZGF0ZXMsIGFnZW50cyB3aWxsDQo+Pj4+ICAgIHRoZXJlZm9yZSBmaXJzdCBpZGVudGlm eSBhbmQgZGlzY2FyZCB0aGUgYXR0cmlidXRlIGxpbmVzIGNvbnRhaW5pbmcNCj4+Pj4gICAgY2Fu ZGlkYXRlcyB0aGV5IGhhdmUgYWxyZWFkeSByZWNlaXZlZCBpbiBwcmV2aW91cyBJTkZPIHJlcXVl c3RzIG9yDQo+Pj4+aW4NCj4+Pj4gICAgdGhlIE9mZmVyL0Fuc3dlciBleGNoYW5nZSBwcmVjZWRp bmcgdGhlbS4gIFR3byBjYW5kaWRhdGVzIGFyZQ0KPj4+PiAgICBjb25zaWRlcmVkIHRvIGJlIGVx dWFsIGlmIHRoZWlyIElQIGFkZHJlc3MgcG9ydCwgdHJhbnNwb3J0IGFuZA0KPj4+PiAgICBjb21w b25lbnQgSUQgYXJlIHRoZSBzYW1lLiAgQWZ0ZXIgaWRlbnRpZnlpbmcgYW5kIGRpc2NhcmRpbmcg a25vd24NCj4+Pj4gICAgY2FuZGlkYXRlcywgdGhlIElDRSBhZ2VudHMgd2lsbCB0aGVuIHByb2Nl c3MgdGhlIHJlbWFpbmluZywNCj4+Pj5hY3R1YWxseQ0KPj4+PiAgICBuZXcgY2FuZGlkYXRlcyBh Y2NvcmRpbmcgdG8gdGhlIHJ1bGVzIGRlc2NyaWJlZCBpbg0KPj4+PiAgICBbSS1ELmlldGYtaWNl LXRyaWNrbGUNCj4+Pj4gDQo+Pj4+PGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1p ZXRmLW1tdXNpYy10cmlja2xlLWljZS1zaXAtMDcjcmVmLUkNCj4+Pj4tRC4NCj4+Pj4gaWV0Zi1p Y2UtdHJpY2tsZT5dLg0KPj4+Pg0KPj4+PiBTbywgdGhlIHJlcXVpcmVtZW50IGlzIGNvdmVyZWQg YnkgdGhlIHNlY29uZCBwYXJhZ3JhcGguDQo+Pj4+DQo+Pj4+IFJlZ2FyZHMNCj4+Pj4gVGhvbWFz DQo+Pj4+DQo+Pj4+Pg0KPj4+Pj4gUmVnYXJkcywNCj4+Pj4+DQo+Pj4+PiBDaHJpc3Rlcg0KPj4+ Pj4NCj4+Pj4+DQo+PiANCj4NCg0K From nobody Wed Jun 14 23:22:38 2017 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E602129B08 for ; Wed, 14 Jun 2017 23:22:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 EbHZo5Y_PceQ for ; Wed, 14 Jun 2017 23:22:34 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73A74129AF9 for ; Wed, 14 Jun 2017 23:22:34 -0700 (PDT) X-AuditID: c1b4fb3a-307ff70000004a6a-92-594227a7aa94 Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.183.42]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 05.6C.19050.7A722495; Thu, 15 Jun 2017 08:22:32 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.30]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.03.0339.000; Thu, 15 Jun 2017 08:22:31 +0200 From: Christer Holmberg To: Peter Saint-Andre , "ice@ietf.org" Thread-Topic: [Ice] draft-trickle-11: Comment on section 3 Thread-Index: AQHS3dX2vHJOf6oHg0GY4LkU+XNtoqIbu4yAgAl7eYCAAF+NAA== Date: Thu, 15 Jun 2017 06:22:30 +0000 Message-ID: References: <0b357375-8759-ee20-9ca5-a473ffa92cb0@stpeter.im> <91457c18-f6a7-c496-c0e8-5af5c4d2188e@stpeter.im> In-Reply-To: <91457c18-f6a7-c496-c0e8-5af5c4d2188e@stpeter.im> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.4.170508 x-originating-ip: [153.88.183.19] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <8BA8EAAC95F1BC479AFF8D35E73D43CE@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprEIsWRmVeSWpSXmKPExsUyM2K7lu4KdadIg8n35S2+Xai1OLann9mB yWPJkp9MHnP3vGAOYIrisklJzcksSy3St0vgypjWOpWtoJW74vX5f2wNjCc5uhg5OSQETCRa 5yxm72Lk4hASOMIocbvhMiNIQkhgMaPE17t5XYwcHGwCFhLd/7RBwiICnhIXf69kA7GFBSwl bl65yQoRt5KYfvgwC4TtJDHt0Q+wMSwCqhLb3zxgBrF5Bawlfk/tY4LYBTT+wcKXYM2cAnYS /5fdA7MZBcQkvp9awwRiMwuIS9x6Mp8J4lABiSV7zjND2KISLx//YwW5TVRAT+Ldfk+IsKJE +9MGRohWPYkbU6ewQdjWEt/PTWeBsLUlli18DXWPoMTJmU9YJjCKzUKybRaS9llI2mchaZ+F pH0BI+sqRtHi1OLi3HQjI73Uoszk4uL8PL281JJNjMCYOrjlt9UOxoPPHQ8xCnAwKvHwJrM4 RQqxJpYVV+YeYpTgYFYS4bVVAArxpiRWVqUW5ccXleakFh9ilOZgURLnddh3IUJIID2xJDU7 NbUgtQgmy8TBKdXA6PO0kHeV+IS3b49Od7q3JzvV6bCZpMH+1pfx67tU5J1fVbremCE4V/XN nvfFk5cc9TgQXj5h+64/r1fOPvLe6jdP+OMgn1rXf/Ft/HqfD6jrii+7/mTlI4cPvpr/HNlN 9krN5nX8JWrRXRVwt+cc1/ZZeVtDmuR2li/Y82m2pIZ+e3jghOc7TJRYijMSDbWYi4oTAWoM G4+lAgAA Archived-At: Subject: Re: [Ice] draft-trickle-11: Comment on section 3 X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2017 06:22:36 -0000 Hi, I=B9m ok for now, based on your reply. Regards, Christer On 15/06/17 06:47, "Peter Saint-Andre" wrote: >Christer, is this clear or would you like me to improve the text? > >On 6/8/17 8:59 PM, Peter Saint-Andre wrote: >> On 6/5/17 2:30 AM, Christer Holmberg wrote: >>> *Section 3* >>> >>> The text says: >>> >>> "If an agent determines that the remote party does not support >>>Trickle ICE, it >>> MUST fall back to using regular ICE or abandon the entire session." >>> >>> This is confusing, because earlier the draft says that half trickle can >>> be used if the remote party doesn=B9t support trickle. >>=20 >> Section 2 states: >>=20 >> The [half trickle] >> mechanism is mostly meant for use in cases where the remote >> agent's support for Trickle ICE cannot be confirmed prior to >> conveying the initial ICE parameters. >>=20 >> Not being able to determine the remote agent's support for trickle is >> different from definitively determining that the remote agent does not >> support trickle (the case covered by the text in Section 3). >>=20 >> If this is not sufficiently clear, we can improve the text. >>=20 >>> And, I don=B9t think >>> =B3regular ICE=B2 and =B3half trickle=B2 are the same things, are they? >>=20 >> I don't think the spec implies that they are. >>=20 >> Peter >>=20 >>=20 > From nobody Thu Jun 15 13:52:39 2017 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68DF41293F9 for ; Thu, 15 Jun 2017 13:52:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=stpeter.im header.b=B3h0PXH5; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=ljVBhRLd Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BMV6H3SWicWl for ; Thu, 15 Jun 2017 13:52:35 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B9A8127ABE for ; Thu, 15 Jun 2017 13:52:35 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 5B69B2078B; Thu, 15 Jun 2017 16:52:34 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute2.internal (MEProxy); Thu, 15 Jun 2017 16:52:34 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stpeter.im; h= content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=BnVADclObclkrM+0dr sOqF7NvDggfF1IzOK4CTuFi5M=; b=B3h0PXH5aCh6Xgq6S8v3gcvX/GuenjgQFq rgbcLJ36jji0Xfurb9g3sesQgkDxaRofiOVQI6Ul8WUVnFFYtitRSGznXimdm6a1 0jaiFGCOM0w/b+M4LPEWJvKbms+jH0A3yiORkTUoUTwbEyXq8I5yxqklRLPyxtHi /6lat7GTM4SGMfcgGQAKHbZ3RPUKlCVGKuR+FkSmijp+y5DG3GIOWYBdDE4PC6H0 gmHBrPPMaxkh0TpSm5lNYUcruIY8HWO2y4ZCEPpgj711qJYLhSpGncnQI+FxFS13 /FwJAFDJiqgbQRdWrMQaUKhqn4WaZy6QxIJq6nc4zPMTESd+wZlQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=BnVADclObclkrM+0drsOqF7NvDggfF1IzOK4CTuFi5M=; b=ljVBhRLd WQR4BNGDuUc7xezVKSqmEtZQrFmc2mHzGelxJ4o7y4RJugfKc4v0psB+yHiPjPFr 2LlsFoKUbFTivibBhfdawfn9zGoJ8emtlDtDht1YUJlDBay6+ezkhfsVqC2/nwdt YinSe2i+9joSpmWyespC9KcJ47uiKSQ7cDRaNHFLVZ5Gj9NZfNroOsGuTWOP4l1s Q/WVohdwq67bij/D8j+zyAb4iJs4Ff0GmIwVrVIk86vLgsVL6EeZiPwqgZpDzPEv Ubk3N51QaYThUU8idWd7M8SA1aerd5yYh8rQ2I2qqAnvsWnK/d4yZ2bYzLZ+JCfn fAHDVaC98vsKWA== X-ME-Sender: X-Sasl-enc: yAF4JL2BMa0f66kHZQtJXl0l7PEM/yabHzGFQOB9nDbn 1497559954 Received: from aither.local (unknown [76.25.4.24]) by mail.messagingengine.com (Postfix) with ESMTPA id D94712492D; Thu, 15 Jun 2017 16:52:33 -0400 (EDT) To: Christer Holmberg , "ice@ietf.org" References: <0b357375-8759-ee20-9ca5-a473ffa92cb0@stpeter.im> <91457c18-f6a7-c496-c0e8-5af5c4d2188e@stpeter.im> From: Peter Saint-Andre Message-ID: <232f5547-f946-2cf1-b2c3-31e1fdb24f07@stpeter.im> Date: Thu, 15 Jun 2017 14:52:32 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Ice] draft-trickle-11: Comment on section 3 X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2017 20:52:37 -0000 Great, thanks! Your feedback is appreciated. :-) On 6/15/17 12:22 AM, Christer Holmberg wrote: > Hi, > > I¹m ok for now, based on your reply. > > Regards, > > Christer > > On 15/06/17 06:47, "Peter Saint-Andre" wrote: > >> Christer, is this clear or would you like me to improve the text? >> >> On 6/8/17 8:59 PM, Peter Saint-Andre wrote: >>> On 6/5/17 2:30 AM, Christer Holmberg wrote: >>>> *Section 3* >>>> >>>> The text says: >>>> >>>> "If an agent determines that the remote party does not support >>>> Trickle ICE, it >>>> MUST fall back to using regular ICE or abandon the entire session." >>>> >>>> This is confusing, because earlier the draft says that half trickle can >>>> be used if the remote party doesn¹t support trickle. >>> >>> Section 2 states: >>> >>> The [half trickle] >>> mechanism is mostly meant for use in cases where the remote >>> agent's support for Trickle ICE cannot be confirmed prior to >>> conveying the initial ICE parameters. >>> >>> Not being able to determine the remote agent's support for trickle is >>> different from definitively determining that the remote agent does not >>> support trickle (the case covered by the text in Section 3). >>> >>> If this is not sufficiently clear, we can improve the text. >>> >>>> And, I don¹t think >>>> ³regular ICE² and ³half trickle² are the same things, are they? >>> >>> I don't think the spec implies that they are. >>> >>> Peter >>> From nobody Thu Jun 15 13:59:02 2017 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D15221294C7 for ; Thu, 15 Jun 2017 13:59:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=stpeter.im header.b=OJCHC5A0; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=YNIbMFZN Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zUQTs_djSBfU for ; Thu, 15 Jun 2017 13:58:59 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A7E91293F9 for ; Thu, 15 Jun 2017 13:58:59 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id CD7C220A4C; Thu, 15 Jun 2017 16:58:58 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute2.internal (MEProxy); Thu, 15 Jun 2017 16:58:58 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stpeter.im; h= content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=w5AyNdFN8nvlHYfyRT Hd5dkL2fCVv/NqjbIKbki9agA=; b=OJCHC5A0mUl/Z/NsDio/yb8zyytxdfWv8U LHV60szQ86TW0dgEyiWxQOcEJ9mVGFXdvnpY3MXe9bbqSztCFNYA4Uvhm0OaHrn7 DWUBjz3j/ZueCNVxtwx+ru7fq+aqJ+SCapAyOKmg8ns8vWADx01MeqzTMzqV7rKi b3f5slaJvxlH98SPXXuoje9rMk4JCPzIwIebMmvj0j7p6mBHbdFCYU0I2gSc3rHh 0LmuQJnD6i3njsse0aVKQBcNC9HmtibJdAGfANROOWrtJMpW8LCPXilOIrbiWUon NgPyq489pUuXTsQBHSQef6gfWf3qMvz1Qqn44GGjuk5hPQsDE9gg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=w5AyNdFN8nvlHYfyRTHd5dkL2fCVv/NqjbIKbki9agA=; b=YNIbMFZN UKHfBMuFzn+F1/r/rN4i8ReqXhF02nCilmQlmsPd+MtCTVLERimfgnzDmUW4PKyY eeUMEqdI2sTWKfPeU2K7jRJco+CA3YuUANvTXWPG6pbkhTsP9WWl2OJncJ9KvW8c /gcdumj32AJm2YwGWsnuHdWhnt3VPHpZA1tgWeDXxYx0O9Whb9UCZRScyYdVNpoM nFhlVmgBrXUw1A6RBUogpnvFn08guzbZhIfcMIYJPGDJchsvSTXUR+h5D7cq2LJy hf37vM8SjqKpQWfYki/GdUk3gJRC/otbdLkvcu9eUL2+8JnekwnytIRSgR6fSbFx PIpwkk2VXLUWIA== X-ME-Sender: X-Sasl-enc: lhXSsNQGgyJgW9qcsxuxjxJvOPoOZ/rI1OfLveTJFveS 1497560338 Received: from aither.local (unknown [76.25.4.24]) by mail.messagingengine.com (Postfix) with ESMTPA id 437932492D; Thu, 15 Jun 2017 16:58:58 -0400 (EDT) To: Christer Holmberg , Thomas Stach , "ice@ietf.org" References: <2beef248-4046-927a-fd3b-3be5a6072b8a@stpeter.im> From: Peter Saint-Andre Message-ID: <25609d65-554b-e268-1607-ad4b05d91954@stpeter.im> Date: Thu, 15 Jun 2017 14:58:57 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Ice] draft-trickle-11: Comment on section 15 X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2017 20:59:01 -0000 On 6/15/17 12:20 AM, Christer Holmberg wrote: > > Hi, > > I was writing a reply earlier, but realised it got stucked in my Drafts > folder. > > Before you suggest text, I have a couple of questions on Peter’s earlier > reply. > >>> There are two delivery "levels" here: >>> >>> (a) signaling-layer transport of a particular message (such as a SIP >>> INFO request or XMPP IQ stanza), which could include information about >>> one or more candidates >>> >>> (b) semantic communication of a candidate, potentially across multiple >>> messages (as in the example from draft-ietf-mmusic-trickle-ice-sip) >>> >>> As I understand it, this text in the trickle spec was meant to address >>> (a), not (b). >>> If we're talking about (a), then do people have concerns with specifying >>> that the signaling protocol needs to ensure in-order delivery and "at >>> most once" delivery? (Note that this could include things like acks and >>> retries as necessary in order to ensure delivery.) > > I am not sure whether we need to say “at most onceâ€. Isn’t is enough to > say “ensure deliveryâ€? That's probably fine. Some people care about "at most once" vs. "at least once" (the former is a lot harder). > Why do we need to require in-order delivery? Because that enables the agents to figure out which version of the candidate information is most current. If the initiator sends versions A, B, and C of Candidate 1 in that order, but the responder receives them in the order C, B, A, then confusion will result. >>> If we're talking about (b), then we'd probably want to specify that the >>> signaling protocol needs to send each candidate "at least once", and >>> that endpoints need to detect duplicates. > > I think we could say that the signalling protocol needs to provide a > mechanism for the application to detect duplicates. De-duping is usually done in the user agent. I suppose you're saying that the signalling protocol (e.g., the payload formats for candidate information) need to provide unique identification of each candidate so that the user agent is able to reliably perform de-duplication. Peter From nobody Fri Jun 16 17:52:12 2017 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EEEE124C27 for ; Fri, 16 Jun 2017 17:52:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=stpeter.im header.b=M4G9ceRi; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=mDOY20/y Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gmbp4LGFLAI1 for ; Fri, 16 Jun 2017 17:52:08 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE560128990 for ; Fri, 16 Jun 2017 17:52:07 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 2B5FB207C2; Fri, 16 Jun 2017 20:52:07 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute2.internal (MEProxy); Fri, 16 Jun 2017 20:52:07 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stpeter.im; h= content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=lRKSAciKLT575yG5AX pMGBEI1XSPguHTdALO2jJFpHE=; b=M4G9ceRifK94caAujP3y3+Ais3BVJ3CpxU LjSogTWdlBJkclvV8W0mAxcEC8m86wgPD7qenFZQLMwylEVuWvhvkzIrOubcLEob CTLGTkTJdYBMOeVJD/GZ3Rq1MP55Xw6er37/sAxOYTXkDRbSLtOshaZoKyXegV/O VUDMYu50GTFtuxPVa4r4i82cW81jMxBAa8PR/2hpQz95g+xOHckujFPfUcnHNTmZ 8Pqo9wZQtsVEd5UJWllwPKMwk+m2lN0B7SjK66WlbqaL7bWxMIGImwTNpimMX6dT UI3+gs4i/jgJ4f8boMKb/ZpPVm1MQmp+TbQwPZOZuF910rio8N9g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=lRKSAciKLT575yG5AXpMGBEI1XSPguHTdALO2jJFpHE=; b=mDOY20/y LGgyo4IBCEvIfTGjjOVaQVuN4UPcPjSuvvS6s1Q0rf9GqA+ahLjKmgfPrAcCLy4A m9+3Zs1Ql5yoNFDuHV0CAJweoNfBXoaQO+1Vq2zYcfHKSRtyckaJttrBNxkxxr9C W26jBkvPL11WNkeTKMtYiz554g0U+xmo6VdjJEDXqBEyvR4mcJ72ZhXCUaw8kdHq 1jdLqIMPp6Ra4GYS55BnWPomc27Xmyzx3sp6ZQ8ILJI4XkS0PxH3rmT3a3/zgPZN SeORjJO4OLTHI4joKgjLmgQKE7pkAdpmzrnbwaipxeUdCeO0dSpPtTih5igHQWZx dS+Kf0ybkYoQjQ== X-ME-Sender: X-Sasl-enc: HaqHmT2le4aB8J7Lgy/4ouSqDRFpU1NdjVkToFUQ4MWn 1497660726 Received: from aither.local (unknown [76.25.4.24]) by mail.messagingengine.com (Postfix) with ESMTPA id 9428224767; Fri, 16 Jun 2017 20:52:06 -0400 (EDT) To: Christer Holmberg , Thomas Stach , "ice@ietf.org" References: <2beef248-4046-927a-fd3b-3be5a6072b8a@stpeter.im> <25609d65-554b-e268-1607-ad4b05d91954@stpeter.im> From: Peter Saint-Andre Message-ID: <53d0d853-6832-f86c-20ed-d5f1cc3a9059@stpeter.im> Date: Fri, 16 Jun 2017 18:52:05 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <25609d65-554b-e268-1607-ad4b05d91954@stpeter.im> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Ice] draft-trickle-11: Comment on section 15 X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jun 2017 00:52:11 -0000 On 6/15/17 2:58 PM, Peter Saint-Andre wrote: > On 6/15/17 12:20 AM, Christer Holmberg wrote: >> >> Hi, >> >> I was writing a reply earlier, but realised it got stucked in my Drafts >> folder. >> >> Before you suggest text, I have a couple of questions on Peter’s earlier >> reply. >> >>>> There are two delivery "levels" here: >>>> >>>> (a) signaling-layer transport of a particular message (such as a SIP >>>> INFO request or XMPP IQ stanza), which could include information about >>>> one or more candidates >>>> >>>> (b) semantic communication of a candidate, potentially across multiple >>>> messages (as in the example from draft-ietf-mmusic-trickle-ice-sip) >>>> >>>> As I understand it, this text in the trickle spec was meant to address >>>> (a), not (b). >>>> If we're talking about (a), then do people have concerns with specifying >>>> that the signaling protocol needs to ensure in-order delivery and "at >>>> most once" delivery? (Note that this could include things like acks and >>>> retries as necessary in order to ensure delivery.) >> >> I am not sure whether we need to say “at most onceâ€. Isn’t is enough to >> say “ensure deliveryâ€? > > That's probably fine. Some people care about "at most once" vs. "at > least once" (the former is a lot harder). > >> Why do we need to require in-order delivery? > > Because that enables the agents to figure out which version of the > candidate information is most current. If the initiator sends versions > A, B, and C of Candidate 1 in that order, but the responder receives > them in the order C, B, A, then confusion will result. > >>>> If we're talking about (b), then we'd probably want to specify that the >>>> signaling protocol needs to send each candidate "at least once", and >>>> that endpoints need to detect duplicates. >> >> I think we could say that the signalling protocol needs to provide a >> mechanism for the application to detect duplicates. > > De-duping is usually done in the user agent. I suppose you're saying > that the signalling protocol (e.g., the payload formats for candidate > information) need to provide unique identification of each candidate so > that the user agent is able to reliably perform de-duplication. I've looked into this again. The current text in Section 8 reads: When candidates are trickled, each candidate MUST be delivered to the receiving Trickle ICE implementation not more than once and in the same order it was conveyed. If the signaling protocol provides any candidate retransmissions, they need to be hidden from the ICE implementation. Christer, can you live with that text? If not, we could impose a less strict requirement on the signaling protocol (i.e., "at least once" delivery and unique identification of each instance of candidate information), but at the cost of more complexity in the user agent (because it might need to perform de-duplication). Personally I don't see a compelling need to modify the existing text. I've provisionally made fixes to all the other issues raised during WGLC and can post version -12 as soon as we agree on this issue. Peter From nobody Sun Jun 18 23:58:17 2017 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EAE9128D3E for ; Sun, 18 Jun 2017 23:58:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1JRPsicgkJ-F for ; Sun, 18 Jun 2017 23:58:14 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60397127180 for ; Sun, 18 Jun 2017 23:58:13 -0700 (PDT) X-AuditID: c1b4fb25-545149a0000046b1-a5-59477603bac6 Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.183.42]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 7D.C6.18097.30677495; Mon, 19 Jun 2017 08:58:11 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.25]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.03.0339.000; Mon, 19 Jun 2017 08:58:11 +0200 From: Christer Holmberg To: Peter Saint-Andre , Thomas Stach , "ice@ietf.org" Thread-Topic: [Ice] draft-trickle-11: Comment on section 15 Thread-Index: AQHS3dZ/cBKgt2WVVE+FUUPx8uxmV6IWj0eAgADorQCABEoNgIAJdM+AgABfOQCAAMErgIAB03iAgAO/OoA= Date: Mon, 19 Jun 2017 06:58:10 +0000 Message-ID: References: <2beef248-4046-927a-fd3b-3be5a6072b8a@stpeter.im> <25609d65-554b-e268-1607-ad4b05d91954@stpeter.im> <53d0d853-6832-f86c-20ed-d5f1cc3a9059@stpeter.im> In-Reply-To: <53d0d853-6832-f86c-20ed-d5f1cc3a9059@stpeter.im> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.4.170508 x-originating-ip: [153.88.183.16] Content-Type: text/plain; charset="Windows-1252" Content-ID: <9EDD69DC51B29B4699A545076618C941@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprBIsWRmVeSWpSXmKPExsUyM2K7li5zmXukwf1eC4tvF2otju3pZ7b4 dGIrkwOzx85Zd9k9liz5yeQxd88L5gDmKC6blNSczLLUIn27BK6Mw1e3MBas4ay4/kmpgXE9 excjB4eEgInE+mnxXYxcHEICRxgljmw+zALhLGaUWL/pNTNIEZuAhUT3P+0uRk4OEYFiiTW/ ZzOB2MICVhJtUxcxQsStJTY+OM0CUi4ikCRx/aArSJhFQFVi87cVLCA2L1DJnBcX2SHGL2KW WHZ6NzNIglPATuJey0cwm1FATOL7qTVg85kFxCVuPZkPZksICEgs2XOeGcIWlXj5+B8ryC5R AT2Jd/s9IcKKEjvPtjNDtBpIvD83H+x6ZqC9Hz+6QoS1JZYtfM0McY6gxMmZT1gmMIrNQrJs FpLuWQjds5B0z0LSvYCRdRWjaHFqcVJuupGxXmpRZnJxcX6eXl5qySZGYHwd3PJbdQfj5TeO hxgFOBiVeHhrUt0jhVgTy4orcw8xSnAwK4nwRmUAhXhTEiurUovy44tKc1KLDzFKc7AoifM6 7rsQISSQnliSmp2aWpBaBJNl4uCUamAUdv4jwvtn1a+2WUL5O/uc6qc9mFJUfP6b3rIbK6XY 1r7fvvTfLfmC9nNn7ZtXZ2/w6lAu2TQps+LSb7mk7AkS6VxqSoUfJG/NebT/SmPT3pu/Vt/z FPR7e7Plht+i3atWs+3NfnRF1KSjI+Te4m83eK0+l15g+ra92vFGQe/Vdbf33NskrG22R4ml OCPRUIu5qDgRAKlzRYWrAgAA Archived-At: Subject: Re: [Ice] draft-trickle-11: Comment on section 15 X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2017 06:58:16 -0000 Hi, =8A > >I've looked into this again. The current text in Section 8 reads: > > When candidates are trickled, each candidate MUST be delivered to the > receiving Trickle ICE implementation not more than once and in the > same order it was conveyed. If the signaling protocol provides any > candidate retransmissions, they need to be hidden from the ICE > implementation. > >Christer, can you live with that text? > >If not, we could impose a less strict requirement on the signaling >protocol (i.e., "at least once" delivery and unique identification of >each instance of candidate information), but at the cost of more >complexity in the user agent (because it might need to perform >de-duplication). > >Personally I don't see a compelling need to modify the existing text. > >I've provisionally made fixes to all the other issues raised during WGLC >and can post version -12 as soon as we agree on this issue. THAT text I am ok with :) My issue was the requirement text. I don=B9t think the requirement text is aligned with the text above, because the requirement text explicitly talks about the signalling protocol. Regards, Christer From nobody Mon Jun 19 15:05:04 2017 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE2A8129329 for ; Mon, 19 Jun 2017 15:05:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=stpeter.im header.b=D1+a/MNC; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=V9+PdzZ6 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R8P8q-VuD-Pe for ; Mon, 19 Jun 2017 15:05:01 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73F901200CF for ; Mon, 19 Jun 2017 15:05:01 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id A7DC420B56; Mon, 19 Jun 2017 18:05:00 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute2.internal (MEProxy); Mon, 19 Jun 2017 18:05:00 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stpeter.im; h= content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=HD90V1MiccXsc7FDFR PLaHhgQZRr3b4TQUeGEcoQWXE=; b=D1+a/MNCSP5J4ZfR3KZgT/lN0dvNOCw8B/ T5qJjlA3YicgvkIleOV1hUcOB2dniwkyD08lUQ72D8zjgVAjsPdAUWyUT9WnTBY1 sBEA3SmXsIBlndmad+4khsW7wDdOXPLXAZ52y/M7nX+UD2JOvoKXV1c3NTCkrfxz cWUYQgZUwXzaFdZx7tiFUzFI9suYSNzKhIp6nZOyDshpQTxnaXle7M8WiHtm1NHB y/7GXpBN70CtDYKK2ETn7LeIEV4A3RveCnItw5nC/T5jLBARl98UayTUxAzKSpKA ZPmrPglKQdoiKS0TIofwLsF3c46yA+OdufgBoZn0nhKFKNHbS/8Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=HD90V1MiccXsc7FDFRPLaHhgQZRr3b4TQUeGEcoQWXE=; b=V9+PdzZ6 Up6s4TeRbtDISXbvcJvkyPFhmmePAh9T7k5h1JMYT7LI6BaU0aoBL63kWfAlqPsm tavuWl2PFqvY42dsiYGw50CsO43YU+o5tcG2qgceYts4R6KO+W/g0pJDbcbJydZ9 VMfgBw3ZrXJLm+9d5o+j05FCfO+iKP2uJHMInxTpa6sc0SJt08fQK5XNozCWOEA+ 7aUZHHMt12Li8w+Vw3+fFHqt2TrYy8zu8BCeLj0z1XyXRG1pwG9SYmS58p3Mlan9 RyNgl/w6/Arnjs3qRPP+cZFcpLuNv7kDd1cEeiRQwLXrNBlOtSdjSrpivSGZzHN2 tb+Rs1QDxynNfQ== X-ME-Sender: X-Sasl-enc: zt+bDvQgRi8/rfiAsGUooVoc614FRPTeSV5UJ5NgklJE 1497909900 Received: from aither.local (unknown [76.25.4.24]) by mail.messagingengine.com (Postfix) with ESMTPA id 1BE2D2475E; Mon, 19 Jun 2017 18:04:59 -0400 (EDT) To: Christer Holmberg , Thomas Stach , "ice@ietf.org" References: <2beef248-4046-927a-fd3b-3be5a6072b8a@stpeter.im> <25609d65-554b-e268-1607-ad4b05d91954@stpeter.im> <53d0d853-6832-f86c-20ed-d5f1cc3a9059@stpeter.im> From: Peter Saint-Andre Message-ID: Date: Mon, 19 Jun 2017 16:04:59 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Ice] draft-trickle-11: Comment on section 15 X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2017 22:05:04 -0000 On 6/19/17 12:58 AM, Christer Holmberg wrote: > Hi, > > Š > > >> >> I've looked into this again. The current text in Section 8 reads: >> >> When candidates are trickled, each candidate MUST be delivered to the >> receiving Trickle ICE implementation not more than once and in the >> same order it was conveyed. If the signaling protocol provides any >> candidate retransmissions, they need to be hidden from the ICE >> implementation. >> >> Christer, can you live with that text? >> >> If not, we could impose a less strict requirement on the signaling >> protocol (i.e., "at least once" delivery and unique identification of >> each instance of candidate information), but at the cost of more >> complexity in the user agent (because it might need to perform >> de-duplication). >> >> Personally I don't see a compelling need to modify the existing text. >> >> I've provisionally made fixes to all the other issues raised during WGLC >> and can post version -12 as soon as we agree on this issue. > > > THAT text I am ok with :) > > My issue was the requirement text. I don¹t think the requirement text is > aligned with the text above, because the requirement text explicitly talks > about the signalling protocol. Section 15 "Requirements for Signaling Protocols" is our attempt to capture in one place (for convenience) all the requirements that the trickle method places on signaling protocols, and to point back from there to the relevant sections in the specification. I don't see a conflict between the text in Section 8: When candidates are trickled, each candidate MUST be delivered to the receiving Trickle ICE implementation not more than once and in the same order it was conveyed. If the signaling protocol provides any candidate retransmissions, they need to be hidden from the ICE implementation. And the text in Section 15: o A signaling protocol MUST deliver each trickled candidate not more than once and in the same order it was conveyed (see Section 8). Is your concern that the text in Section 8 uses the passive voice whereas Section 15 explicitly mentions this as a requirement for the signaling protocol? It's not clear to me what else provides delivery services, if not the signaling protocol... Peter From nobody Wed Jun 21 11:37:01 2017 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19F5A12948B for ; Wed, 21 Jun 2017 11:36:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=stpeter.im header.b=mYNPg86/; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=AUTFaF3Y Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id igKVUBUuEk_W for ; Wed, 21 Jun 2017 11:36:54 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5507129477 for ; Wed, 21 Jun 2017 11:36:12 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id E728C206A7; Wed, 21 Jun 2017 14:36:11 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute2.internal (MEProxy); Wed, 21 Jun 2017 14:36:11 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stpeter.im; h= content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=SWqgtfSwnmorjZE9+A gv59vy/+6daj5sTgI8m9T+Eug=; b=mYNPg86/JMGDKe+7Grn+/kQtmW3ddiQZGk PKrWaebAUE5lfPHRsTnQ1kh909vtInEjS1JarVyJe0Z2uPMRf2mPZfL7FV6DXoLy GKi3fp2H/U3+6cmJwf5r7Cs2CGatIDm31YCy+6ZMfWw227FRZjYGIFGmA3vqnWXV rKBptKbd0QkILqdt3qr0W0ocprVU8Sj3ZrV6lyjpjqVIdNYSOtLngR4UV0JUPjUC DRqeNh89VGVJMMEyTipa/7ra1EBUZ2hhW2Q1XQ1o9qVF7qV3L55H0IuoPeFLOEKk w3wqvD2Itn2XeC5Ccsg+NUZIl6fjJsVD3ETsKagE/ACs0hvFbyWg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=SWqgtfSwnmorjZE9+Agv59vy/+6daj5sTgI8m9T+Eug=; b=AUTFaF3Y GwlMdn0DF2RmW0k0J++gFXpS+r8Y87/KVbjF53gr9AmFir1DxJlHDnai3OjuXV3b 8AnsFOhldvBDxJSx1BWqDhhVQgVFbkxdxpP3KMLARE0gqYfS0vQo0HUF9B3Gq+OT gO/hfMXVK3hANRyUZIVsNh38hmJ3kPusdMcVpN/FO8dSougXQaP2bBZHuoIUGqIu DxzuEf2VHtbR7w6oJB14LzZrUPWx3Q62KO09bnvriz5eD/iHcu5+Y5UfecexQnH6 EYati3ScuWPv5GcvG3g7ox2K+A8msELyHNE8bS+aFX6G6GpsWU0KLmH1bJfyZ/Gu oQHMFS6Ju9akUw== X-ME-Sender: X-Sasl-enc: TvMyEgbteKGieg5ww7HDormTX+9L3OkqaGWADWT4TjUD 1498070171 Received: from aither.local (unknown [76.25.4.24]) by mail.messagingengine.com (Postfix) with ESMTPA id 557B07E755; Wed, 21 Jun 2017 14:36:11 -0400 (EDT) To: Christer Holmberg , Thomas Stach , "ice@ietf.org" References: <2beef248-4046-927a-fd3b-3be5a6072b8a@stpeter.im> <25609d65-554b-e268-1607-ad4b05d91954@stpeter.im> <53d0d853-6832-f86c-20ed-d5f1cc3a9059@stpeter.im> From: Peter Saint-Andre Message-ID: <1d9cb246-9325-1a5f-aefb-0d8bbec0ea89@stpeter.im> Date: Wed, 21 Jun 2017 12:36:10 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Ice] draft-trickle-11: Comment on section 15 X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 18:36:56 -0000 On 6/19/17 4:04 PM, Peter Saint-Andre wrote: > On 6/19/17 12:58 AM, Christer Holmberg wrote: >> Hi, >> >> Š >> >> >>> >>> I've looked into this again. The current text in Section 8 reads: >>> >>> When candidates are trickled, each candidate MUST be delivered to the >>> receiving Trickle ICE implementation not more than once and in the >>> same order it was conveyed. If the signaling protocol provides any >>> candidate retransmissions, they need to be hidden from the ICE >>> implementation. >>> >>> Christer, can you live with that text? >>> >>> If not, we could impose a less strict requirement on the signaling >>> protocol (i.e., "at least once" delivery and unique identification of >>> each instance of candidate information), but at the cost of more >>> complexity in the user agent (because it might need to perform >>> de-duplication). >>> >>> Personally I don't see a compelling need to modify the existing text. >>> >>> I've provisionally made fixes to all the other issues raised during WGLC >>> and can post version -12 as soon as we agree on this issue. >> >> >> THAT text I am ok with :) >> >> My issue was the requirement text. I don¹t think the requirement text is >> aligned with the text above, because the requirement text explicitly talks >> about the signalling protocol. > > Section 15 "Requirements for Signaling Protocols" is our attempt to > capture in one place (for convenience) all the requirements that the > trickle method places on signaling protocols, and to point back from > there to the relevant sections in the specification. > > I don't see a conflict between the text in Section 8: > > When candidates are trickled, each candidate MUST be delivered to the > receiving Trickle ICE implementation not more than once and in the > same order it was conveyed. If the signaling protocol provides any > candidate retransmissions, they need to be hidden from the ICE > implementation. > > And the text in Section 15: > > o A signaling protocol MUST deliver each trickled candidate not more > than once and in the same order it was conveyed (see Section 8). > > Is your concern that the text in Section 8 uses the passive voice > whereas Section 15 explicitly mentions this as a requirement for the > signaling protocol? It's not clear to me what else provides delivery > services, if not the signaling protocol... Because the passive voice is confusing here in Section 8, I suggest that we modify that text to read: When candidates are trickled, the signaling protocol MUST deliver each candidate to the receiving Trickle ICE implementation not more than once and in the same order it was conveyed. If the signaling protocol provides any candidate retransmissions, they need to be hidden from the ICE implementation. If you can't live with this text, please say so in the next ~24 hours. Around that time I will submit version -12 to address WGLC feedback. Thanks! Peter From nobody Wed Jun 21 22:21:21 2017 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4851A1200CF for ; Wed, 21 Jun 2017 22:21:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QIvLj2Rgi_n4 for ; Wed, 21 Jun 2017 22:21:17 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46CAE12943B for ; Wed, 21 Jun 2017 22:21:17 -0700 (PDT) X-AuditID: c1b4fb2d-2bf039a00000080d-01-594b53cbfd21 Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.183.36]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 05.A4.02061.BC35B495; Thu, 22 Jun 2017 07:21:15 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.25]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.03.0339.000; Thu, 22 Jun 2017 07:21:13 +0200 From: Christer Holmberg To: Peter Saint-Andre , Thomas Stach , "ice@ietf.org" Thread-Topic: [Ice] draft-trickle-11: Comment on section 15 Thread-Index: AQHS3dZ/cBKgt2WVVE+FUUPx8uxmV6IWj0eAgADorQCABEoNgIAJdM+AgABfOQCAAMErgIAB03iAgAO/OoCAAMkVgIAC6lIAgADmfYA= Date: Thu, 22 Jun 2017 05:21:12 +0000 Message-ID: References: <2beef248-4046-927a-fd3b-3be5a6072b8a@stpeter.im> <25609d65-554b-e268-1607-ad4b05d91954@stpeter.im> <53d0d853-6832-f86c-20ed-d5f1cc3a9059@stpeter.im> <1d9cb246-9325-1a5f-aefb-0d8bbec0ea89@stpeter.im> In-Reply-To: <1d9cb246-9325-1a5f-aefb-0d8bbec0ea89@stpeter.im> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.4.170508 x-originating-ip: [153.88.183.19] Content-Type: text/plain; charset="euc-kr" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprLIsWRmVeSWpSXmKPExsUyM2K7iu7pYO9IgyeHJC2+Xai1OLann9ni 04mtTA7MHjtn3WX3WLLkJ5PH3D0vmAOYo7hsUlJzMstSi/TtErgy3i59xlhwQKHiwNO3bA2M V+S7GDk5JARMJD6s7GPrYuTiEBI4wiixfT2Ms5hRYsafI8xdjBwcbAIWEt3/tEEaRASKJdb8 ns0EYgsLWEm0TV3ECBG3ltj44DQLhF0msar3OlgNi4CqxLW2b2A1vEA10yfuY4aYv4dF4urG HmaQBKeAncS3q9vAbEYBMYnvp9aANTMLiEvcejKfCeJSAYkle84zQ9iiEi8f/2MFuU1UQE/i 3X5PiLCiRPvTBkaIVi2JLz/2sUHY1hLrP7+CGqkoMaX7ITvEPYISJ2c+YZnAKDYLybZZSNpn IWmfhaR9FpL2BYysqxhFi1OLi3PTjYz1Uosyk4uL8/P08lJLNjECI+3glt+6OxhXv3Y8xCjA wajEw5tq6x0pxJpYVlyZe4hRgoNZSYRXwwUoxJuSWFmVWpQfX1Sak1p8iFGag0VJnNdh34UI IYH0xJLU7NTUgtQimCwTB6dUA+PqXss8Vk/JxtQNXO8ChQy+XUtm9Ll15oWxdetdc8Hfizr3 c/or/33H96M70/r5RknfS7uKRW/f+/Tg9mrxOZJKwiaF4ScSZdMz10dM7HWrfn5DapNBju4c zV8h1/dZdhnu39yt6pO50vHypaWXkx0dXHxY2KS3b126+IX5bvl3Bh/Yl32TsVViKc5INNRi LipOBABy/isgsAIAAA== Archived-At: Subject: Re: [Ice] draft-trickle-11: Comment on section 15 X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2017 05:21:19 -0000 SGksDQoNCj4+Pj5JJ3ZlIGxvb2tlZCBpbnRvIHRoaXMgYWdhaW4uIFRoZSBjdXJyZW50IHRleHQg aW4gU2VjdGlvbiA4IHJlYWRzOg0KPj4+Pg0KPj4+PiAgIFdoZW4gY2FuZGlkYXRlcyBhcmUgdHJp Y2tsZWQsIGVhY2ggY2FuZGlkYXRlIE1VU1QgYmUgZGVsaXZlcmVkIHRvDQo+Pj4+dGhlDQo+Pj4+ ICAgcmVjZWl2aW5nIFRyaWNrbGUgSUNFIGltcGxlbWVudGF0aW9uIG5vdCBtb3JlIHRoYW4gb25j ZSBhbmQgaW4gdGhlDQo+Pj4+ICAgc2FtZSBvcmRlciBpdCB3YXMgY29udmV5ZWQuICBJZiB0aGUg c2lnbmFsaW5nIHByb3RvY29sIHByb3ZpZGVzIGFueQ0KPj4+PiAgIGNhbmRpZGF0ZSByZXRyYW5z bWlzc2lvbnMsIHRoZXkgbmVlZCB0byBiZSBoaWRkZW4gZnJvbSB0aGUgSUNFDQo+Pj4+ICAgaW1w bGVtZW50YXRpb24uDQo+Pj4+DQo+Pj4+IENocmlzdGVyLCBjYW4geW91IGxpdmUgd2l0aCB0aGF0 IHRleHQ/DQo+Pj4+DQo+Pj4+IElmIG5vdCwgd2UgY291bGQgaW1wb3NlIGEgbGVzcyBzdHJpY3Qg cmVxdWlyZW1lbnQgb24gdGhlIHNpZ25hbGluZw0KPj4+PiBwcm90b2NvbCAoaS5lLiwgImF0IGxl YXN0IG9uY2UiIGRlbGl2ZXJ5IGFuZCB1bmlxdWUgaWRlbnRpZmljYXRpb24gb2YNCj4+Pj4gZWFj aCBpbnN0YW5jZSBvZiBjYW5kaWRhdGUgaW5mb3JtYXRpb24pLCBidXQgYXQgdGhlIGNvc3Qgb2Yg bW9yZQ0KPj4+PiBjb21wbGV4aXR5IGluIHRoZSB1c2VyIGFnZW50IChiZWNhdXNlIGl0IG1pZ2h0 IG5lZWQgdG8gcGVyZm9ybQ0KPj4+PiBkZS1kdXBsaWNhdGlvbikuDQo+Pj4+DQo+Pj4+IFBlcnNv bmFsbHkgSSBkb24ndCBzZWUgYSBjb21wZWxsaW5nIG5lZWQgdG8gbW9kaWZ5IHRoZSBleGlzdGlu ZyB0ZXh0Lg0KPj4+Pg0KPj4+PiBJJ3ZlIHByb3Zpc2lvbmFsbHkgbWFkZSBmaXhlcyB0byBhbGwg dGhlIG90aGVyIGlzc3VlcyByYWlzZWQgZHVyaW5nDQo+Pj4+V0dMQw0KPj4+PiBhbmQgY2FuIHBv c3QgdmVyc2lvbiAtMTIgYXMgc29vbiBhcyB3ZSBhZ3JlZSBvbiB0aGlzIGlzc3VlLg0KPj4+DQo+ Pj4NCj4+PiBUSEFUIHRleHQgSSBhbSBvayB3aXRoIDopDQo+Pj4NCj4+PiBNeSBpc3N1ZSB3YXMg dGhlIHJlcXVpcmVtZW50IHRleHQuIEkgZG9uqfZ0IHRoaW5rIHRoZSByZXF1aXJlbWVudCB0ZXh0 DQo+Pj5pcw0KPj4+IGFsaWduZWQgd2l0aCB0aGUgdGV4dCBhYm92ZSwgYmVjYXVzZSB0aGUgcmVx dWlyZW1lbnQgdGV4dCBleHBsaWNpdGx5DQo+Pj50YWxrcw0KPj4+IGFib3V0IHRoZSBzaWduYWxs aW5nIHByb3RvY29sLg0KPj4gDQo+PiBTZWN0aW9uIDE1ICJSZXF1aXJlbWVudHMgZm9yIFNpZ25h bGluZyBQcm90b2NvbHMiIGlzIG91ciBhdHRlbXB0IHRvDQo+PiBjYXB0dXJlIGluIG9uZSBwbGFj ZSAoZm9yIGNvbnZlbmllbmNlKSBhbGwgdGhlIHJlcXVpcmVtZW50cyB0aGF0IHRoZQ0KPj4gdHJp Y2tsZSBtZXRob2QgcGxhY2VzIG9uIHNpZ25hbGluZyBwcm90b2NvbHMsIGFuZCB0byBwb2ludCBi YWNrIGZyb20NCj4+IHRoZXJlIHRvIHRoZSByZWxldmFudCBzZWN0aW9ucyBpbiB0aGUgc3BlY2lm aWNhdGlvbi4NCj4+IA0KPj4gSSBkb24ndCBzZWUgYSBjb25mbGljdCBiZXR3ZWVuIHRoZSB0ZXh0 IGluIFNlY3Rpb24gODoNCj4+IA0KPj4gICAgV2hlbiBjYW5kaWRhdGVzIGFyZSB0cmlja2xlZCwg ZWFjaCBjYW5kaWRhdGUgTVVTVCBiZSBkZWxpdmVyZWQgdG8gdGhlDQo+PiAgICByZWNlaXZpbmcg VHJpY2tsZSBJQ0UgaW1wbGVtZW50YXRpb24gbm90IG1vcmUgdGhhbiBvbmNlIGFuZCBpbiB0aGUN Cj4+ICAgIHNhbWUgb3JkZXIgaXQgd2FzIGNvbnZleWVkLiAgSWYgdGhlIHNpZ25hbGluZyBwcm90 b2NvbCBwcm92aWRlcyBhbnkNCj4+ICAgIGNhbmRpZGF0ZSByZXRyYW5zbWlzc2lvbnMsIHRoZXkg bmVlZCB0byBiZSBoaWRkZW4gZnJvbSB0aGUgSUNFDQo+PiAgICBpbXBsZW1lbnRhdGlvbi4NCj4+ IA0KPj4gQW5kIHRoZSB0ZXh0IGluIFNlY3Rpb24gMTU6DQo+PiANCj4+ICAgIG8gIEEgc2lnbmFs aW5nIHByb3RvY29sIE1VU1QgZGVsaXZlciBlYWNoIHRyaWNrbGVkIGNhbmRpZGF0ZSBub3QgbW9y ZQ0KPj4gICAgICAgdGhhbiBvbmNlIGFuZCBpbiB0aGUgc2FtZSBvcmRlciBpdCB3YXMgY29udmV5 ZWQgKHNlZSBTZWN0aW9uIDgpLg0KPj4gDQo+PiBJcyB5b3VyIGNvbmNlcm4gdGhhdCB0aGUgdGV4 dCBpbiBTZWN0aW9uIDggdXNlcyB0aGUgcGFzc2l2ZSB2b2ljZQ0KPj4gd2hlcmVhcyBTZWN0aW9u IDE1IGV4cGxpY2l0bHkgbWVudGlvbnMgdGhpcyBhcyBhIHJlcXVpcmVtZW50IGZvciB0aGUNCj4+ IHNpZ25hbGluZyBwcm90b2NvbD8gSXQncyBub3QgY2xlYXIgdG8gbWUgd2hhdCBlbHNlIHByb3Zp ZGVzIGRlbGl2ZXJ5DQo+PiBzZXJ2aWNlcywgaWYgbm90IHRoZSBzaWduYWxpbmcgcHJvdG9jb2wu Li4NCj4NCj5CZWNhdXNlIHRoZSBwYXNzaXZlIHZvaWNlIGlzIGNvbmZ1c2luZyBoZXJlIGluIFNl Y3Rpb24gOCwgSSBzdWdnZXN0IHRoYXQNCj53ZSBtb2RpZnkgdGhhdCB0ZXh0IHRvIHJlYWQ6DQo+ DQo+ICAgV2hlbiBjYW5kaWRhdGVzIGFyZSB0cmlja2xlZCwgdGhlIHNpZ25hbGluZyBwcm90b2Nv bCBNVVNUIGRlbGl2ZXINCj4gICBlYWNoIGNhbmRpZGF0ZSB0byB0aGUgcmVjZWl2aW5nIFRyaWNr bGUgSUNFIGltcGxlbWVudGF0aW9uIG5vdCBtb3JlDQo+ICAgdGhhbiBvbmNlIGFuZCBpbiB0aGUg c2FtZSBvcmRlciBpdCB3YXMgY29udmV5ZWQuICBJZiB0aGUgc2lnbmFsaW5nDQo+ICAgcHJvdG9j b2wgcHJvdmlkZXMgYW55IGNhbmRpZGF0ZSByZXRyYW5zbWlzc2lvbnMsIHRoZXkgbmVlZCB0byBi ZQ0KPiAgIGhpZGRlbiBmcm9tIHRoZSBJQ0UgaW1wbGVtZW50YXRpb24uDQo+DQo+SWYgeW91IGNh bid0IGxpdmUgd2l0aCB0aGlzIHRleHQsIHBsZWFzZSBzYXkgc28gaW4gdGhlIG5leHQgfjI0IGhv dXJzLg0KPkFyb3VuZCB0aGF0IHRpbWUgSSB3aWxsIHN1Ym1pdCB2ZXJzaW9uIC0xMiB0byBhZGRy ZXNzIFdHTEMgZmVlZGJhY2suDQoNCkkgY2FuIGxpdmUgd2l0aCB0aGUgdGV4dC4NCg0KUmVnYXJk cywNCg0KQ2hyaXN0ZXINCg0K From nobody Thu Jun 22 07:39:21 2017 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2827C1298BA for ; Thu, 22 Jun 2017 07:39:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=stpeter.im header.b=icAM5KJV; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=NgfOUx4R Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hbMlZJFBZ4ne for ; Thu, 22 Jun 2017 07:39:18 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 172881296C9 for ; Thu, 22 Jun 2017 07:39:18 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 820D4209ED; Thu, 22 Jun 2017 10:39:17 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute2.internal (MEProxy); Thu, 22 Jun 2017 10:39:17 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stpeter.im; h= content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=WHrMXwU/0JvLBzEBdM XzFAQog80+DpHOz2ePxWpsAOc=; b=icAM5KJVb7CXPGLyR59UCGfellIbiX0ife vO8PqGZ+A3Y75HDi0eHToRXsIXW8H4tjUQ2+VzTkGI1ADJBrgMET2Iln/tSwEGUN aQ6GKPHWVURelr9VXtAoBhdBmgaJDpIwUMqad7WoFpg1vERAvW64PdDyDZbqFfif iZpQQ0bUKbLsZeNiyYDH0HthzCcvHk2GEO3OXuFqdtHzoarnLrGnbyARbwze0zWY skue4JlLCcNNC5utC2GQ31b4El0sajJg/AlsHRip1NeLNCj0CwUXh6ZlSOT7RQm7 ySy+omhj4sv+jq2Sbxj7BCkSe+FBc5wV4JI4zj3gUw9/YLc+8dew== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=WHrMXwU/0JvLBzEBdMXzFAQog80+DpHOz2ePxWpsAOc=; b=NgfOUx4R imabiOLP21tKBUZ1BRJoqfs17vrsNk/GXa1l+pL8qHitrgeLSrBWu/vo4sP5P9Dh eF92Nbe8XobTb65sePyOuIghojslEumc9ApLavP1freTme7gciCESxy+42t5D7ZJ eU0s/FTu7F/nOR36a/n+I/kbQLjp5M3oc6PSHG6oMGleGqxYK+rO/ggWTZSMadwA B5S/4EdWUV2uNKaQMyE7TwZSn4Gfd55LJEYWmsV9WhS7NT7VBOep1HeCvwVPOEpN Vd97yhQMI2Sj5LgNQ5ApZrCo1o8Cg4cqLVbtTkPz2CBYc6fN3JLbMh6hr5V1W71Y 8m+IETKaqJ4owg== X-ME-Sender: X-Sasl-enc: wo/Fka7HhTIejw3WG5Szv9PDkE54hLF0n3rSQGXKk61g 1498142357 Received: from aither.local (unknown [76.25.4.24]) by mail.messagingengine.com (Postfix) with ESMTPA id F21737E1FA; Thu, 22 Jun 2017 10:39:16 -0400 (EDT) To: Christer Holmberg , Thomas Stach , "ice@ietf.org" References: <2beef248-4046-927a-fd3b-3be5a6072b8a@stpeter.im> <25609d65-554b-e268-1607-ad4b05d91954@stpeter.im> <53d0d853-6832-f86c-20ed-d5f1cc3a9059@stpeter.im> <1d9cb246-9325-1a5f-aefb-0d8bbec0ea89@stpeter.im> From: Peter Saint-Andre Message-ID: <143fe708-80fa-7d3f-8b46-7e0692d721e2@stpeter.im> Date: Thu, 22 Jun 2017 08:39:14 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=euc-kr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Ice] draft-trickle-11: Comment on section 15 X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2017 14:39:20 -0000 On 6/21/17 11:21 PM, Christer Holmberg wrote: > Hi, > >>>>> I've looked into this again. The current text in Section 8 reads: >>>>> >>>>> When candidates are trickled, each candidate MUST be delivered to >>>>> the >>>>> receiving Trickle ICE implementation not more than once and in the >>>>> same order it was conveyed. If the signaling protocol provides any >>>>> candidate retransmissions, they need to be hidden from the ICE >>>>> implementation. >>>>> >>>>> Christer, can you live with that text? >>>>> >>>>> If not, we could impose a less strict requirement on the signaling >>>>> protocol (i.e., "at least once" delivery and unique identification of >>>>> each instance of candidate information), but at the cost of more >>>>> complexity in the user agent (because it might need to perform >>>>> de-duplication). >>>>> >>>>> Personally I don't see a compelling need to modify the existing text. >>>>> >>>>> I've provisionally made fixes to all the other issues raised during >>>>> WGLC >>>>> and can post version -12 as soon as we agree on this issue. >>>> >>>> >>>> THAT text I am ok with :) >>>> >>>> My issue was the requirement text. I don©öt think the requirement text >>>> is >>>> aligned with the text above, because the requirement text explicitly >>>> talks >>>> about the signalling protocol. >>> >>> Section 15 "Requirements for Signaling Protocols" is our attempt to >>> capture in one place (for convenience) all the requirements that the >>> trickle method places on signaling protocols, and to point back from >>> there to the relevant sections in the specification. >>> >>> I don't see a conflict between the text in Section 8: >>> >>> When candidates are trickled, each candidate MUST be delivered to the >>> receiving Trickle ICE implementation not more than once and in the >>> same order it was conveyed. If the signaling protocol provides any >>> candidate retransmissions, they need to be hidden from the ICE >>> implementation. >>> >>> And the text in Section 15: >>> >>> o A signaling protocol MUST deliver each trickled candidate not more >>> than once and in the same order it was conveyed (see Section 8). >>> >>> Is your concern that the text in Section 8 uses the passive voice >>> whereas Section 15 explicitly mentions this as a requirement for the >>> signaling protocol? It's not clear to me what else provides delivery >>> services, if not the signaling protocol... >> >> Because the passive voice is confusing here in Section 8, I suggest that >> we modify that text to read: >> >> When candidates are trickled, the signaling protocol MUST deliver >> each candidate to the receiving Trickle ICE implementation not more >> than once and in the same order it was conveyed. If the signaling >> protocol provides any candidate retransmissions, they need to be >> hidden from the ICE implementation. >> >> If you can't live with this text, please say so in the next ~24 hours. >> Around that time I will submit version -12 to address WGLC feedback. > > I can live with the text. OK, great. I'll wait until this evening in my timezone to publish -12. Peter From nobody Thu Jun 22 09:14:34 2017 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49618129AD5 for ; Thu, 22 Jun 2017 09:14:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.101 X-Spam-Level: X-Spam-Status: No, score=-1.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=1.5, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iARvGe6FWU4B for ; Thu, 22 Jun 2017 09:14:32 -0700 (PDT) Received: from mx0b-00198e01.pphosted.com (mx0b-00198e01.pphosted.com [67.231.157.197]) (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 D9624129AD4 for ; Thu, 22 Jun 2017 09:14:31 -0700 (PDT) Received: from pps.filterd (m0073110.ppops.net [127.0.0.1]) by mx0b-00198e01.pphosted.com (8.16.0.20/8.16.0.20) with SMTP id v5MGE4Yg003497; Thu, 22 Jun 2017 12:14:26 -0400 Received: from mail.vidyo.com (mail2.vidyo.com [162.209.16.214]) by mx0b-00198e01.pphosted.com with ESMTP id 2b88hrr973-1 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NOT); Thu, 22 Jun 2017 12:14:25 -0400 Received: from 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77]) by 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62%13]) with mapi id 14.03.0195.001; Thu, 22 Jun 2017 11:14:25 -0500 From: Jonathan Lennox To: Christer Holmberg CC: Peter Saint-Andre , Thomas Stach , "ice@ietf.org" Thread-Topic: [Ice] draft-trickle-11: Comment on section 15 Thread-Index: AQHS3dZ/cBKgt2WVVE+FUUPx8uxmV6IWj0eAgADorQCABEoNgIAJdM+AgABfOQCAAMErgIAB03iAgAO/OoCAAMkVgIAC6lIAgADmfYCAAPmXAA== Date: Thu, 22 Jun 2017 16:14:24 +0000 Message-ID: References: <2beef248-4046-927a-fd3b-3be5a6072b8a@stpeter.im> <25609d65-554b-e268-1607-ad4b05d91954@stpeter.im> <53d0d853-6832-f86c-20ed-d5f1cc3a9059@stpeter.im> <1d9cb246-9325-1a5f-aefb-0d8bbec0ea89@stpeter.im> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [160.79.219.114] Content-Type: text/plain; charset="utf-8" Content-ID: <88B1CD2F565C97418AF6EA000160F044@vidyo.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-22_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706220279 Archived-At: Subject: Re: [Ice] draft-trickle-11: Comment on section 15 X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2017 16:14:33 -0000 U28gdGhpcyByZXF1aXJlbWVudCBtZWFucyB0aGF0IGZvciBXZWJSVEMsIGVpdGhlciB0aGlzIGlz IGEgcmVxdWlyZW1lbnQgb24gSmF2YXNjcmlwdCBhcHBsaWNhdGlvbiBpbXBsZW1lbnRvcnMsIG9y IGVsc2UgSlNFUCB3aWxsIG5lZWQgc29tZSB3YXkgb2YgZG9pbmcgZGVkdXBsaWNhdGlvbiBhbmQg bG9zcyBkZXRlY3Rpb24uIEFyZSBwZW9wbGUgb2theSB3aXRoIHRoYXQ/DQoNCj4gT24gSnVuIDIy LCAyMDE3LCBhdCAxOjIxIEFNLCBDaHJpc3RlciBIb2xtYmVyZyA8Y2hyaXN0ZXIuaG9sbWJlcmdA ZXJpY3Nzb24uY29tPiB3cm90ZToNCj4gDQo+IEhpLA0KPiANCj4+Pj4+IEkndmUgbG9va2VkIGlu dG8gdGhpcyBhZ2Fpbi4gVGhlIGN1cnJlbnQgdGV4dCBpbiBTZWN0aW9uIDggcmVhZHM6DQo+Pj4+ PiANCj4+Pj4+ICBXaGVuIGNhbmRpZGF0ZXMgYXJlIHRyaWNrbGVkLCBlYWNoIGNhbmRpZGF0ZSBN VVNUIGJlIGRlbGl2ZXJlZCB0bw0KPj4+Pj4gdGhlDQo+Pj4+PiAgcmVjZWl2aW5nIFRyaWNrbGUg SUNFIGltcGxlbWVudGF0aW9uIG5vdCBtb3JlIHRoYW4gb25jZSBhbmQgaW4gdGhlDQo+Pj4+PiAg c2FtZSBvcmRlciBpdCB3YXMgY29udmV5ZWQuICBJZiB0aGUgc2lnbmFsaW5nIHByb3RvY29sIHBy b3ZpZGVzIGFueQ0KPj4+Pj4gIGNhbmRpZGF0ZSByZXRyYW5zbWlzc2lvbnMsIHRoZXkgbmVlZCB0 byBiZSBoaWRkZW4gZnJvbSB0aGUgSUNFDQo+Pj4+PiAgaW1wbGVtZW50YXRpb24uDQo+Pj4+PiAN Cj4+Pj4+IENocmlzdGVyLCBjYW4geW91IGxpdmUgd2l0aCB0aGF0IHRleHQ/DQo+Pj4+PiANCj4+ Pj4+IElmIG5vdCwgd2UgY291bGQgaW1wb3NlIGEgbGVzcyBzdHJpY3QgcmVxdWlyZW1lbnQgb24g dGhlIHNpZ25hbGluZw0KPj4+Pj4gcHJvdG9jb2wgKGkuZS4sICJhdCBsZWFzdCBvbmNlIiBkZWxp dmVyeSBhbmQgdW5pcXVlIGlkZW50aWZpY2F0aW9uIG9mDQo+Pj4+PiBlYWNoIGluc3RhbmNlIG9m IGNhbmRpZGF0ZSBpbmZvcm1hdGlvbiksIGJ1dCBhdCB0aGUgY29zdCBvZiBtb3JlDQo+Pj4+PiBj b21wbGV4aXR5IGluIHRoZSB1c2VyIGFnZW50IChiZWNhdXNlIGl0IG1pZ2h0IG5lZWQgdG8gcGVy Zm9ybQ0KPj4+Pj4gZGUtZHVwbGljYXRpb24pLg0KPj4+Pj4gDQo+Pj4+PiBQZXJzb25hbGx5IEkg ZG9uJ3Qgc2VlIGEgY29tcGVsbGluZyBuZWVkIHRvIG1vZGlmeSB0aGUgZXhpc3RpbmcgdGV4dC4N Cj4+Pj4+IA0KPj4+Pj4gSSd2ZSBwcm92aXNpb25hbGx5IG1hZGUgZml4ZXMgdG8gYWxsIHRoZSBv dGhlciBpc3N1ZXMgcmFpc2VkIGR1cmluZw0KPj4+Pj4gV0dMQw0KPj4+Pj4gYW5kIGNhbiBwb3N0 IHZlcnNpb24gLTEyIGFzIHNvb24gYXMgd2UgYWdyZWUgb24gdGhpcyBpc3N1ZS4NCj4+Pj4gDQo+ Pj4+IA0KPj4+PiBUSEFUIHRleHQgSSBhbSBvayB3aXRoIDopDQo+Pj4+IA0KPj4+PiBNeSBpc3N1 ZSB3YXMgdGhlIHJlcXVpcmVtZW50IHRleHQuIEkgZG9uwrl0IHRoaW5rIHRoZSByZXF1aXJlbWVu dCB0ZXh0DQo+Pj4+IGlzDQo+Pj4+IGFsaWduZWQgd2l0aCB0aGUgdGV4dCBhYm92ZSwgYmVjYXVz ZSB0aGUgcmVxdWlyZW1lbnQgdGV4dCBleHBsaWNpdGx5DQo+Pj4+IHRhbGtzDQo+Pj4+IGFib3V0 IHRoZSBzaWduYWxsaW5nIHByb3RvY29sLg0KPj4+IA0KPj4+IFNlY3Rpb24gMTUgIlJlcXVpcmVt ZW50cyBmb3IgU2lnbmFsaW5nIFByb3RvY29scyIgaXMgb3VyIGF0dGVtcHQgdG8NCj4+PiBjYXB0 dXJlIGluIG9uZSBwbGFjZSAoZm9yIGNvbnZlbmllbmNlKSBhbGwgdGhlIHJlcXVpcmVtZW50cyB0 aGF0IHRoZQ0KPj4+IHRyaWNrbGUgbWV0aG9kIHBsYWNlcyBvbiBzaWduYWxpbmcgcHJvdG9jb2xz LCBhbmQgdG8gcG9pbnQgYmFjayBmcm9tDQo+Pj4gdGhlcmUgdG8gdGhlIHJlbGV2YW50IHNlY3Rp b25zIGluIHRoZSBzcGVjaWZpY2F0aW9uLg0KPj4+IA0KPj4+IEkgZG9uJ3Qgc2VlIGEgY29uZmxp Y3QgYmV0d2VlbiB0aGUgdGV4dCBpbiBTZWN0aW9uIDg6DQo+Pj4gDQo+Pj4gICBXaGVuIGNhbmRp ZGF0ZXMgYXJlIHRyaWNrbGVkLCBlYWNoIGNhbmRpZGF0ZSBNVVNUIGJlIGRlbGl2ZXJlZCB0byB0 aGUNCj4+PiAgIHJlY2VpdmluZyBUcmlja2xlIElDRSBpbXBsZW1lbnRhdGlvbiBub3QgbW9yZSB0 aGFuIG9uY2UgYW5kIGluIHRoZQ0KPj4+ICAgc2FtZSBvcmRlciBpdCB3YXMgY29udmV5ZWQuICBJ ZiB0aGUgc2lnbmFsaW5nIHByb3RvY29sIHByb3ZpZGVzIGFueQ0KPj4+ICAgY2FuZGlkYXRlIHJl dHJhbnNtaXNzaW9ucywgdGhleSBuZWVkIHRvIGJlIGhpZGRlbiBmcm9tIHRoZSBJQ0UNCj4+PiAg IGltcGxlbWVudGF0aW9uLg0KPj4+IA0KPj4+IEFuZCB0aGUgdGV4dCBpbiBTZWN0aW9uIDE1Og0K Pj4+IA0KPj4+ICAgbyAgQSBzaWduYWxpbmcgcHJvdG9jb2wgTVVTVCBkZWxpdmVyIGVhY2ggdHJp Y2tsZWQgY2FuZGlkYXRlIG5vdCBtb3JlDQo+Pj4gICAgICB0aGFuIG9uY2UgYW5kIGluIHRoZSBz YW1lIG9yZGVyIGl0IHdhcyBjb252ZXllZCAoc2VlIFNlY3Rpb24gOCkuDQo+Pj4gDQo+Pj4gSXMg eW91ciBjb25jZXJuIHRoYXQgdGhlIHRleHQgaW4gU2VjdGlvbiA4IHVzZXMgdGhlIHBhc3NpdmUg dm9pY2UNCj4+PiB3aGVyZWFzIFNlY3Rpb24gMTUgZXhwbGljaXRseSBtZW50aW9ucyB0aGlzIGFz IGEgcmVxdWlyZW1lbnQgZm9yIHRoZQ0KPj4+IHNpZ25hbGluZyBwcm90b2NvbD8gSXQncyBub3Qg Y2xlYXIgdG8gbWUgd2hhdCBlbHNlIHByb3ZpZGVzIGRlbGl2ZXJ5DQo+Pj4gc2VydmljZXMsIGlm IG5vdCB0aGUgc2lnbmFsaW5nIHByb3RvY29sLi4uDQo+PiANCj4+IEJlY2F1c2UgdGhlIHBhc3Np dmUgdm9pY2UgaXMgY29uZnVzaW5nIGhlcmUgaW4gU2VjdGlvbiA4LCBJIHN1Z2dlc3QgdGhhdA0K Pj4gd2UgbW9kaWZ5IHRoYXQgdGV4dCB0byByZWFkOg0KPj4gDQo+PiAgV2hlbiBjYW5kaWRhdGVz IGFyZSB0cmlja2xlZCwgdGhlIHNpZ25hbGluZyBwcm90b2NvbCBNVVNUIGRlbGl2ZXINCj4+ICBl YWNoIGNhbmRpZGF0ZSB0byB0aGUgcmVjZWl2aW5nIFRyaWNrbGUgSUNFIGltcGxlbWVudGF0aW9u IG5vdCBtb3JlDQo+PiAgdGhhbiBvbmNlIGFuZCBpbiB0aGUgc2FtZSBvcmRlciBpdCB3YXMgY29u dmV5ZWQuICBJZiB0aGUgc2lnbmFsaW5nDQo+PiAgcHJvdG9jb2wgcHJvdmlkZXMgYW55IGNhbmRp ZGF0ZSByZXRyYW5zbWlzc2lvbnMsIHRoZXkgbmVlZCB0byBiZQ0KPj4gIGhpZGRlbiBmcm9tIHRo ZSBJQ0UgaW1wbGVtZW50YXRpb24uDQo+PiANCj4+IElmIHlvdSBjYW4ndCBsaXZlIHdpdGggdGhp cyB0ZXh0LCBwbGVhc2Ugc2F5IHNvIGluIHRoZSBuZXh0IH4yNCBob3Vycy4NCj4+IEFyb3VuZCB0 aGF0IHRpbWUgSSB3aWxsIHN1Ym1pdCB2ZXJzaW9uIC0xMiB0byBhZGRyZXNzIFdHTEMgZmVlZGJh Y2suDQoNCg== From nobody Fri Jun 23 13:59:31 2017 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90F76129447 for ; Fri, 23 Jun 2017 13:59:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=stpeter.im header.b=kqXT+Vyl; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=At1I+Oap Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hTXNhSG-75-i for ; Fri, 23 Jun 2017 13:59:28 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4B2E127444 for ; Fri, 23 Jun 2017 13:59:27 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 5CD2A20AD9; Fri, 23 Jun 2017 16:59:27 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute2.internal (MEProxy); Fri, 23 Jun 2017 16:59:27 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stpeter.im; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=LPPFC8oVEkuZk1xwVc RVBIGpOM6oJFkEsZE80+oBnu8=; b=kqXT+Vyl/FYTLWC3hMsmT61qjasHCSleIl C18xm+/63/CtMEtpQQ89vR6SCgPAyyfl/wCnOwMdOUtO/21oekIL0Fcoqmw70vO1 mc0thI/dgDEKTr2GJS2NdJKnMMEjF/T0geAEhJcFCUbI+M2d7PbwzY6M8btXOF6s xxlymNs7gRjU6F6hJHZaZA9+Ft3a/IqnGK29mot4ol86OOaxYknKpCT585pkn5jA DochkXkrSYix9z4137KKVWoJRkX0L03yCfp8K0HVm8fayrvVUpifE4SQgJ5BYmdd DiFtMyXAOQLqk3SWiW5omcpDoeLVSm3F8QTjSakV0lYRgQH2TjOA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=LPPFC8oVEkuZk1xwVcRVBIGpOM6oJFkEsZE80+oBnu8=; b=At1I+Oap azRhxG6oGLIzBhPtp+vwOBGolEd5Pli735SCU1bF1wcg3lid4tu92d6oy2zlPHT1 /0PToQUzSfZksodAv3A8JCPgMCtS/9UB3H+/oAOn83BYAibaT0k6kSsaeQmvfk6i NQ/wryA7UrIcZAZ5aKX0oK3vgM4L5NwCuoT2LryoAKoIgLJPJ9jIPDddqNX8ds/K ltsyz42czQHSTNFCzj3/nGttE8VcONi/20qLU5XvqVx2WSJU+o+7BJlmogQpAcOh XcNY5Sirmvd4+oZq3hIuyfUotTtWi50pfARojhGRUniJRM7cRKb4ixNPEzxGMUhq scPr1lc/0rk6aw== X-ME-Sender: X-Sasl-enc: x+BcTQnF0ugVtabfiP3S3nwmzOIH0wFRWBma89lmtbhE 1498251566 Received: from aither.local (unknown [76.25.4.24]) by mail.messagingengine.com (Postfix) with ESMTPA id 9E4FB7E271; Fri, 23 Jun 2017 16:59:26 -0400 (EDT) To: Jonathan Lennox , Christer Holmberg References: <2beef248-4046-927a-fd3b-3be5a6072b8a@stpeter.im> <25609d65-554b-e268-1607-ad4b05d91954@stpeter.im> <53d0d853-6832-f86c-20ed-d5f1cc3a9059@stpeter.im> <1d9cb246-9325-1a5f-aefb-0d8bbec0ea89@stpeter.im> Cc: Thomas Stach , "ice@ietf.org" From: Peter Saint-Andre Message-ID: <8a4bf763-33ee-d138-67e3-859f1e5dfe90@stpeter.im> Date: Fri, 23 Jun 2017 14:59:25 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Ice] draft-trickle-11: Comment on section 15 X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jun 2017 20:59:30 -0000 On 6/22/17 10:14 AM, Jonathan Lennox wrote: > So this requirement means that for WebRTC, either this is a requirement on Javascript application implementors, or else JSEP will need some way of doing deduplication and loss detection. Are people okay with that? I can't speak for JSEP, but if an application uses a signaling protocol that doesn't provide in-order delivery then it will need to perform de-duplication no matter what we say. Loss detection is a bit harder for a single user agent to handle on its own. The other approach we can take is to say SHOULD (not MUST) and then describe what the user agent developer needs to consider if using a less "robust" signaling protocol. Peter >> On Jun 22, 2017, at 1:21 AM, Christer Holmberg wrote: >> >> Hi, >> >>>>>> I've looked into this again. The current text in Section 8 reads: >>>>>> >>>>>> When candidates are trickled, each candidate MUST be delivered to >>>>>> the >>>>>> receiving Trickle ICE implementation not more than once and in the >>>>>> same order it was conveyed. If the signaling protocol provides any >>>>>> candidate retransmissions, they need to be hidden from the ICE >>>>>> implementation. >>>>>> >>>>>> Christer, can you live with that text? >>>>>> >>>>>> If not, we could impose a less strict requirement on the signaling >>>>>> protocol (i.e., "at least once" delivery and unique identification of >>>>>> each instance of candidate information), but at the cost of more >>>>>> complexity in the user agent (because it might need to perform >>>>>> de-duplication). >>>>>> >>>>>> Personally I don't see a compelling need to modify the existing text. >>>>>> >>>>>> I've provisionally made fixes to all the other issues raised during >>>>>> WGLC >>>>>> and can post version -12 as soon as we agree on this issue. >>>>> >>>>> >>>>> THAT text I am ok with :) >>>>> >>>>> My issue was the requirement text. I don¹t think the requirement text >>>>> is >>>>> aligned with the text above, because the requirement text explicitly >>>>> talks >>>>> about the signalling protocol. >>>> >>>> Section 15 "Requirements for Signaling Protocols" is our attempt to >>>> capture in one place (for convenience) all the requirements that the >>>> trickle method places on signaling protocols, and to point back from >>>> there to the relevant sections in the specification. >>>> >>>> I don't see a conflict between the text in Section 8: >>>> >>>> When candidates are trickled, each candidate MUST be delivered to the >>>> receiving Trickle ICE implementation not more than once and in the >>>> same order it was conveyed. If the signaling protocol provides any >>>> candidate retransmissions, they need to be hidden from the ICE >>>> implementation. >>>> >>>> And the text in Section 15: >>>> >>>> o A signaling protocol MUST deliver each trickled candidate not more >>>> than once and in the same order it was conveyed (see Section 8). >>>> >>>> Is your concern that the text in Section 8 uses the passive voice >>>> whereas Section 15 explicitly mentions this as a requirement for the >>>> signaling protocol? It's not clear to me what else provides delivery >>>> services, if not the signaling protocol... >>> >>> Because the passive voice is confusing here in Section 8, I suggest that >>> we modify that text to read: >>> >>> When candidates are trickled, the signaling protocol MUST deliver >>> each candidate to the receiving Trickle ICE implementation not more >>> than once and in the same order it was conveyed. If the signaling >>> protocol provides any candidate retransmissions, they need to be >>> hidden from the ICE implementation. >>> >>> If you can't live with this text, please say so in the next ~24 hours. >>> Around that time I will submit version -12 to address WGLC feedback. > From nobody Fri Jun 23 17:18:05 2017 Return-Path: X-Original-To: ice@ietf.org Delivered-To: ice@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 832491292FC; Fri, 23 Jun 2017 17:07:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "\"IETF Secretariat\"" To: , Cc: ben@nostrum.com, ice@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149826283953.7840.6554973027593412210.idtracker@ietfa.amsl.com> Date: Fri, 23 Jun 2017 17:07:19 -0700 Archived-At: Subject: [Ice] ice - Requested session has been scheduled for IETF 99 X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jun 2017 00:07:21 -0000 Dear Ari Keränen, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. ice Session 1 (2:00:00) Thursday, Afternoon Session I 1330-1530 Room Name: Berlin/Brussels size: 100 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: Interactive Connectivity Establishment Area Name: Applications and Real-Time Area Session Requester: Ari Keränen Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 35 Conflicts to Avoid: First Priority: payload core rtcweb avtext avtcore t2trg tls tsvarea tsvwg tram mmusic dispatch tcpm quic Second Priority: perc httpbis rmcat netvc sipbrandy stir Third Priority: ace 6lo lwig clue xrblock sipcore cbor People who must be present: Ben Campbell Ari Keranen Peter Thatcher Resources Requested: Special Requests: --------------------------------------------------------- From nobody Sat Jun 24 01:49:02 2017 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97FCB127868 for ; Sat, 24 Jun 2017 01:49:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KJU_MvZx1Aut for ; Sat, 24 Jun 2017 01:48:59 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67AF31242F5 for ; Sat, 24 Jun 2017 01:48:58 -0700 (PDT) X-AuditID: c1b4fb25-eedff700000016ef-cb-594e2778f8dd Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.183.24]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 00.57.05871.8772E495; Sat, 24 Jun 2017 10:48:56 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.25]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.03.0339.000; Sat, 24 Jun 2017 10:48:56 +0200 From: Christer Holmberg To: Peter Saint-Andre , Jonathan Lennox CC: Thomas Stach , "ice@ietf.org" Thread-Topic: [Ice] draft-trickle-11: Comment on section 15 Thread-Index: AQHS3dZ/cBKgt2WVVE+FUUPx8uxmV6IWj0eAgADorQCABEoNgIAJdM+AgABfOQCAAMErgIAB03iAgAO/OoCAAMkVgIAC6lIAgADmfYCAAPmXAIABbJuAgADll1A= Date: Sat, 24 Jun 2017 08:48:56 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4CC1E276@ESESSMB109.ericsson.se> References: <2beef248-4046-927a-fd3b-3be5a6072b8a@stpeter.im> <25609d65-554b-e268-1607-ad4b05d91954@stpeter.im> <53d0d853-6832-f86c-20ed-d5f1cc3a9059@stpeter.im> <1d9cb246-9325-1a5f-aefb-0d8bbec0ea89@stpeter.im> <8a4bf763-33ee-d138-67e3-859f1e5dfe90@stpeter.im> In-Reply-To: <8a4bf763-33ee-d138-67e3-859f1e5dfe90@stpeter.im> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuphkeLIzCtJLcpLzFFi42KZGbFdQrdC3S/SYOdjPYtvF2ot9i8+z2xx bE8/s8WnE1uZHFg8ds66y+6xZMlPJo+5e14we7Q9u8MewBLFZZOSmpNZllqkb5fAlfH92ynG gjeGFf/OzWFrYDxh0MXIySEhYCJxu7eFuYuRi0NI4AijxP2PL5kgnMWMEqePrwJyODjYBCwk uv9pgzSICARJfNyxiw3EZhbwlOh838UCUiIsYCXxuS8EosRaYuOD0ywQdhejxOb9RiA2i4Cq xLMVXWwg5bwCvhJbLotAbLrKKvHj1E52kBpOATuJzTf2gY1nFBCT+H5qDRPEKnGJW0/mM0Hc LCCxZM95ZghbVOLl43+sELaSxNrD28HOYRbQlFi/Sx+iVVFiSvdDsPG8AoISJ2c+YZnAKDoL ydRZCB2zkHTMQtKxgJFlFaNocWpxUm66kbFealFmcnFxfp5eXmrJJkZgHB3c8lt1B+PlN46H GAU4GJV4ePOu+0YKsSaWFVfmHmKU4GBWEuG9IukXKcSbklhZlVqUH19UmpNafIhRmoNFSZzX cd+FCCGB9MSS1OzU1ILUIpgsEwenVAOjk0jMoyPrVxzU3pFiouNbNo3R/nNq4rLtK9vqDmWq zanxsPr44KNwxSlfaVGFa5mHVsSFztp56a8Ld8KSJb7Nx3tWeX07dMbnbPJB3q8+ZlHz50y9 Yl+2v/dQ0JkLSvJTjm51MS2V/P/ZPrG5pXWvq/c36dmXv8p65fxvDqq9dyyfJ//sBMcrSizF GYmGWsxFxYkAi6vcmp8CAAA= Archived-At: Subject: Re: [Ice] draft-trickle-11: Comment on section 15 X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jun 2017 08:49:01 -0000 SGksDQoNCktlZXAgaW4gbWluZCB0aGF0IGluLW9yZGVyIGRlbGl2ZXJ5LCBsb3NzIGRldGVjdGlv biBhbmQgZHVwbGljYXRpb24gYXJlIGFsbCBzZXBhcmF0ZSB0aGluZ3MuDQoNCkZvciBleGFtcGxl LCB3aXRoIFNJUCB0cmlja2xlLCBjb3JlIFNJUCBwcm92aWRlcyBjZXJ0YWluIG1lY2hhbmlzbXMg dG8gaGVscCB3aXRoIGluLW9yZGVyIGRlbGl2ZXJ5IChhbmQgeW91IGNhbiBpbXByb3ZlIHRoYXQg d2l0aGluIHRoZSBJbmZvIFBhY2thZ2Ugc3BlY2lmaWNhdGlvbiBpZiBuZWVkZWQpLCBidXQgdGhl IGRldGVjdGlvbiBvZiBjYW5kaWRhdGUgZHVwbGljYXRpb24gd2lsbCBoYXZlIHRvIGJlIHRha2Vu IGNhcmUgb2YgdGhlIGFwcGxpY2F0aW9uIC0gd2hhdGV2ZXIgdGhhdCBtZWFucyBpbiBXZWJSVEMu DQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpG cm9tOiBQZXRlciBTYWludC1BbmRyZSBbbWFpbHRvOnN0cGV0ZXJAc3RwZXRlci5pbV0gDQpTZW50 OiAyMyBKdW5lIDIwMTcgMjI6NTkNClRvOiBKb25hdGhhbiBMZW5ub3ggPGpvbmF0aGFuQHZpZHlv LmNvbT47IENocmlzdGVyIEhvbG1iZXJnIDxjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+ DQpDYzogVGhvbWFzIFN0YWNoIDx0aG9tYXNzLnN0YWNoQGdtYWlsLmNvbT47IGljZUBpZXRmLm9y Zw0KU3ViamVjdDogUmU6IFtJY2VdIGRyYWZ0LXRyaWNrbGUtMTE6IENvbW1lbnQgb24gc2VjdGlv biAxNQ0KDQpPbiA2LzIyLzE3IDEwOjE0IEFNLCBKb25hdGhhbiBMZW5ub3ggd3JvdGU6DQo+IFNv IHRoaXMgcmVxdWlyZW1lbnQgbWVhbnMgdGhhdCBmb3IgV2ViUlRDLCBlaXRoZXIgdGhpcyBpcyBh IHJlcXVpcmVtZW50IG9uIEphdmFzY3JpcHQgYXBwbGljYXRpb24gaW1wbGVtZW50b3JzLCBvciBl bHNlIEpTRVAgd2lsbCBuZWVkIHNvbWUgd2F5IG9mIGRvaW5nIGRlZHVwbGljYXRpb24gYW5kIGxv c3MgZGV0ZWN0aW9uLiBBcmUgcGVvcGxlIG9rYXkgd2l0aCB0aGF0Pw0KDQpJIGNhbid0IHNwZWFr IGZvciBKU0VQLCBidXQgaWYgYW4gYXBwbGljYXRpb24gdXNlcyBhIHNpZ25hbGluZyBwcm90b2Nv bCB0aGF0IGRvZXNuJ3QgcHJvdmlkZSBpbi1vcmRlciBkZWxpdmVyeSB0aGVuIGl0IHdpbGwgbmVl ZCB0byBwZXJmb3JtIGRlLWR1cGxpY2F0aW9uIG5vIG1hdHRlciB3aGF0IHdlIHNheS4gTG9zcyBk ZXRlY3Rpb24gaXMgYSBiaXQgaGFyZGVyIGZvciBhIHNpbmdsZSB1c2VyIGFnZW50IHRvIGhhbmRs ZSBvbiBpdHMgb3duLg0KDQpUaGUgb3RoZXIgYXBwcm9hY2ggd2UgY2FuIHRha2UgaXMgdG8gc2F5 IFNIT1VMRCAobm90IE1VU1QpIGFuZCB0aGVuIGRlc2NyaWJlIHdoYXQgdGhlIHVzZXIgYWdlbnQg ZGV2ZWxvcGVyIG5lZWRzIHRvIGNvbnNpZGVyIGlmIHVzaW5nIGEgbGVzcyAicm9idXN0IiBzaWdu YWxpbmcgcHJvdG9jb2wuDQoNClBldGVyDQoNCj4+IE9uIEp1biAyMiwgMjAxNywgYXQgMToyMSBB TSwgQ2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4gd3Jv dGU6DQo+Pg0KPj4gSGksDQo+Pg0KPj4+Pj4+IEkndmUgbG9va2VkIGludG8gdGhpcyBhZ2Fpbi4g VGhlIGN1cnJlbnQgdGV4dCBpbiBTZWN0aW9uIDggcmVhZHM6DQo+Pj4+Pj4NCj4+Pj4+PiAgV2hl biBjYW5kaWRhdGVzIGFyZSB0cmlja2xlZCwgZWFjaCBjYW5kaWRhdGUgTVVTVCBiZSBkZWxpdmVy ZWQgDQo+Pj4+Pj4gdG8gdGhlICByZWNlaXZpbmcgVHJpY2tsZSBJQ0UgaW1wbGVtZW50YXRpb24g bm90IG1vcmUgdGhhbiBvbmNlIA0KPj4+Pj4+IGFuZCBpbiB0aGUgIHNhbWUgb3JkZXIgaXQgd2Fz IGNvbnZleWVkLiAgSWYgdGhlIHNpZ25hbGluZyANCj4+Pj4+PiBwcm90b2NvbCBwcm92aWRlcyBh bnkgIGNhbmRpZGF0ZSByZXRyYW5zbWlzc2lvbnMsIHRoZXkgbmVlZCB0byBiZSANCj4+Pj4+PiBo aWRkZW4gZnJvbSB0aGUgSUNFICBpbXBsZW1lbnRhdGlvbi4NCj4+Pj4+Pg0KPj4+Pj4+IENocmlz dGVyLCBjYW4geW91IGxpdmUgd2l0aCB0aGF0IHRleHQ/DQo+Pj4+Pj4NCj4+Pj4+PiBJZiBub3Qs IHdlIGNvdWxkIGltcG9zZSBhIGxlc3Mgc3RyaWN0IHJlcXVpcmVtZW50IG9uIHRoZSANCj4+Pj4+ PiBzaWduYWxpbmcgcHJvdG9jb2wgKGkuZS4sICJhdCBsZWFzdCBvbmNlIiBkZWxpdmVyeSBhbmQg dW5pcXVlIA0KPj4+Pj4+IGlkZW50aWZpY2F0aW9uIG9mIGVhY2ggaW5zdGFuY2Ugb2YgY2FuZGlk YXRlIGluZm9ybWF0aW9uKSwgYnV0IGF0IA0KPj4+Pj4+IHRoZSBjb3N0IG9mIG1vcmUgY29tcGxl eGl0eSBpbiB0aGUgdXNlciBhZ2VudCAoYmVjYXVzZSBpdCBtaWdodCANCj4+Pj4+PiBuZWVkIHRv IHBlcmZvcm0gZGUtZHVwbGljYXRpb24pLg0KPj4+Pj4+DQo+Pj4+Pj4gUGVyc29uYWxseSBJIGRv bid0IHNlZSBhIGNvbXBlbGxpbmcgbmVlZCB0byBtb2RpZnkgdGhlIGV4aXN0aW5nIHRleHQuDQo+ Pj4+Pj4NCj4+Pj4+PiBJJ3ZlIHByb3Zpc2lvbmFsbHkgbWFkZSBmaXhlcyB0byBhbGwgdGhlIG90 aGVyIGlzc3VlcyByYWlzZWQgDQo+Pj4+Pj4gZHVyaW5nIFdHTEMgYW5kIGNhbiBwb3N0IHZlcnNp b24gLTEyIGFzIHNvb24gYXMgd2UgYWdyZWUgb24gdGhpcyANCj4+Pj4+PiBpc3N1ZS4NCj4+Pj4+ DQo+Pj4+Pg0KPj4+Pj4gVEhBVCB0ZXh0IEkgYW0gb2sgd2l0aCA6KQ0KPj4+Pj4NCj4+Pj4+IE15 IGlzc3VlIHdhcyB0aGUgcmVxdWlyZW1lbnQgdGV4dC4gSSBkb27CuXQgdGhpbmsgdGhlIHJlcXVp cmVtZW50IA0KPj4+Pj4gdGV4dCBpcyBhbGlnbmVkIHdpdGggdGhlIHRleHQgYWJvdmUsIGJlY2F1 c2UgdGhlIHJlcXVpcmVtZW50IHRleHQgDQo+Pj4+PiBleHBsaWNpdGx5IHRhbGtzIGFib3V0IHRo ZSBzaWduYWxsaW5nIHByb3RvY29sLg0KPj4+Pg0KPj4+PiBTZWN0aW9uIDE1ICJSZXF1aXJlbWVu dHMgZm9yIFNpZ25hbGluZyBQcm90b2NvbHMiIGlzIG91ciBhdHRlbXB0IHRvIA0KPj4+PiBjYXB0 dXJlIGluIG9uZSBwbGFjZSAoZm9yIGNvbnZlbmllbmNlKSBhbGwgdGhlIHJlcXVpcmVtZW50cyB0 aGF0IA0KPj4+PiB0aGUgdHJpY2tsZSBtZXRob2QgcGxhY2VzIG9uIHNpZ25hbGluZyBwcm90b2Nv bHMsIGFuZCB0byBwb2ludCBiYWNrIA0KPj4+PiBmcm9tIHRoZXJlIHRvIHRoZSByZWxldmFudCBz ZWN0aW9ucyBpbiB0aGUgc3BlY2lmaWNhdGlvbi4NCj4+Pj4NCj4+Pj4gSSBkb24ndCBzZWUgYSBj b25mbGljdCBiZXR3ZWVuIHRoZSB0ZXh0IGluIFNlY3Rpb24gODoNCj4+Pj4NCj4+Pj4gICBXaGVu IGNhbmRpZGF0ZXMgYXJlIHRyaWNrbGVkLCBlYWNoIGNhbmRpZGF0ZSBNVVNUIGJlIGRlbGl2ZXJl ZCB0byB0aGUNCj4+Pj4gICByZWNlaXZpbmcgVHJpY2tsZSBJQ0UgaW1wbGVtZW50YXRpb24gbm90 IG1vcmUgdGhhbiBvbmNlIGFuZCBpbiB0aGUNCj4+Pj4gICBzYW1lIG9yZGVyIGl0IHdhcyBjb252 ZXllZC4gIElmIHRoZSBzaWduYWxpbmcgcHJvdG9jb2wgcHJvdmlkZXMgYW55DQo+Pj4+ICAgY2Fu ZGlkYXRlIHJldHJhbnNtaXNzaW9ucywgdGhleSBuZWVkIHRvIGJlIGhpZGRlbiBmcm9tIHRoZSBJ Q0UNCj4+Pj4gICBpbXBsZW1lbnRhdGlvbi4NCj4+Pj4NCj4+Pj4gQW5kIHRoZSB0ZXh0IGluIFNl Y3Rpb24gMTU6DQo+Pj4+DQo+Pj4+ICAgbyAgQSBzaWduYWxpbmcgcHJvdG9jb2wgTVVTVCBkZWxp dmVyIGVhY2ggdHJpY2tsZWQgY2FuZGlkYXRlIG5vdCBtb3JlDQo+Pj4+ICAgICAgdGhhbiBvbmNl IGFuZCBpbiB0aGUgc2FtZSBvcmRlciBpdCB3YXMgY29udmV5ZWQgKHNlZSBTZWN0aW9uIDgpLg0K Pj4+Pg0KPj4+PiBJcyB5b3VyIGNvbmNlcm4gdGhhdCB0aGUgdGV4dCBpbiBTZWN0aW9uIDggdXNl cyB0aGUgcGFzc2l2ZSB2b2ljZSANCj4+Pj4gd2hlcmVhcyBTZWN0aW9uIDE1IGV4cGxpY2l0bHkg bWVudGlvbnMgdGhpcyBhcyBhIHJlcXVpcmVtZW50IGZvciANCj4+Pj4gdGhlIHNpZ25hbGluZyBw cm90b2NvbD8gSXQncyBub3QgY2xlYXIgdG8gbWUgd2hhdCBlbHNlIHByb3ZpZGVzIA0KPj4+PiBk ZWxpdmVyeSBzZXJ2aWNlcywgaWYgbm90IHRoZSBzaWduYWxpbmcgcHJvdG9jb2wuLi4NCj4+Pg0K Pj4+IEJlY2F1c2UgdGhlIHBhc3NpdmUgdm9pY2UgaXMgY29uZnVzaW5nIGhlcmUgaW4gU2VjdGlv biA4LCBJIHN1Z2dlc3QgDQo+Pj4gdGhhdCB3ZSBtb2RpZnkgdGhhdCB0ZXh0IHRvIHJlYWQ6DQo+ Pj4NCj4+PiAgV2hlbiBjYW5kaWRhdGVzIGFyZSB0cmlja2xlZCwgdGhlIHNpZ25hbGluZyBwcm90 b2NvbCBNVVNUIGRlbGl2ZXIgIA0KPj4+IGVhY2ggY2FuZGlkYXRlIHRvIHRoZSByZWNlaXZpbmcg VHJpY2tsZSBJQ0UgaW1wbGVtZW50YXRpb24gbm90IG1vcmUgIA0KPj4+IHRoYW4gb25jZSBhbmQg aW4gdGhlIHNhbWUgb3JkZXIgaXQgd2FzIGNvbnZleWVkLiAgSWYgdGhlIHNpZ25hbGluZyAgDQo+ Pj4gcHJvdG9jb2wgcHJvdmlkZXMgYW55IGNhbmRpZGF0ZSByZXRyYW5zbWlzc2lvbnMsIHRoZXkg bmVlZCB0byBiZSAgDQo+Pj4gaGlkZGVuIGZyb20gdGhlIElDRSBpbXBsZW1lbnRhdGlvbi4NCj4+ Pg0KPj4+IElmIHlvdSBjYW4ndCBsaXZlIHdpdGggdGhpcyB0ZXh0LCBwbGVhc2Ugc2F5IHNvIGlu IHRoZSBuZXh0IH4yNCBob3Vycy4NCj4+PiBBcm91bmQgdGhhdCB0aW1lIEkgd2lsbCBzdWJtaXQg dmVyc2lvbiAtMTIgdG8gYWRkcmVzcyBXR0xDIGZlZWRiYWNrLg0KPiANCg0K From nobody Sun Jun 25 18:50:59 2017 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F04EA128C82 for ; Sun, 25 Jun 2017 18:50:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=stpeter.im header.b=J6MFpLEb; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=rI4Z+zPK Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gAR_K8F_CBt5 for ; Sun, 25 Jun 2017 18:50:55 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A8EB127867 for ; Sun, 25 Jun 2017 18:50:55 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 6063C20DCF; Sun, 25 Jun 2017 21:50:54 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute2.internal (MEProxy); Sun, 25 Jun 2017 21:50:54 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stpeter.im; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=lqbzJoB+OsN1B091Ew 3pgNx9wDnMb4yQEgLvBmY3s+A=; b=J6MFpLEbSfkfE/q2Li23BbfLvoX2qYs0WN EiEzyTXbMdlnXpm97wGg8zegQXaUBCgC0yQnSae2dVSKU0n8Opol41y2nKM3Ob/x ehRItiQ1jJnFw3kYcXVA3DKBS+YmF9by3wAWHwAe8W3gWs3Ctpa6M6G9JgrjEJAx 8Eysr8epFKLP5Cf94YW0lsYslGjtaQD/umZvDOsfclGtKUPgx50UGYpN34oky94f RSLqlnSKUXy6cMpGx4w0X0g7SeOyMIL4zB50KeBOy3fZHcyGEm13164faBkk9OUc 7HuoZiCDM0dp8fQn+B1Isr7ErThQ4+3D0ejHI+8bjRPlSEbDzAAg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=lqbzJoB+OsN1B091Ew3pgNx9wDnMb4yQEgLvBmY3s+A=; b=rI4Z+zPK U2DmEbOx3X33VBEIEKagEsFWZkqkYOYovIubcYn9kcCMeozMRxACPb5PNu+p7K+r vFDUkwR/4JV8Qixcx1ybDF0B1mhIwGRJKJYmbyIwsErppTiE6kS67au1tFf9v+s4 dl9C/bVQC+bWXvc/iWI5Cflk5zSPbmLc0djslccgzmrNidBbEbS5qP4pwFID+ISh /yuNBfkvC8Y+zaTTrGvTxmFb/ZZLnChu/KMGzqmeI4Y0GOSKoyOg21IjqTY1Ac52 3boyR6kx+RuJo4EOM+5x4NW9fYbnXF5KEffKJRaz/Y4nCvWYZKXO5WhVbLeAXRWz h5HvzWCT/ARATA== X-ME-Sender: X-Sasl-enc: TdKjNiPO9+olWZlO+dHQ9laY4Sgx2x+9lh5E8CagwrZp 1498441854 Received: from aither.local (unknown [76.25.4.24]) by mail.messagingengine.com (Postfix) with ESMTPA id 1542824370; Sun, 25 Jun 2017 21:50:53 -0400 (EDT) To: Christer Holmberg , Jonathan Lennox References: <2beef248-4046-927a-fd3b-3be5a6072b8a@stpeter.im> <25609d65-554b-e268-1607-ad4b05d91954@stpeter.im> <53d0d853-6832-f86c-20ed-d5f1cc3a9059@stpeter.im> <1d9cb246-9325-1a5f-aefb-0d8bbec0ea89@stpeter.im> <8a4bf763-33ee-d138-67e3-859f1e5dfe90@stpeter.im> <7594FB04B1934943A5C02806D1A2204B4CC1E276@ESESSMB109.ericsson.se> Cc: Thomas Stach , "ice@ietf.org" From: Peter Saint-Andre Message-ID: <8f784571-a9b6-b196-089d-8b040a2a921e@stpeter.im> Date: Sun, 25 Jun 2017 19:50:49 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4CC1E276@ESESSMB109.ericsson.se> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Ice] draft-trickle-11: Comment on section 15 X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jun 2017 01:50:57 -0000 On 6/24/17 2:48 AM, Christer Holmberg wrote: > Hi, > > Keep in mind that in-order delivery, loss detection and duplication > are all separate things. Agreed. > For example, with SIP trickle, core SIP provides certain mechanisms > to help with in-order delivery (and you can improve that within the > Info Package specification if needed), but the detection of candidate > duplication will have to be taken care of the application - whatever > that means in WebRTC. Yes, de-duplication is the responsibility of the user agent application. All the signaling protocol needs to do in this context is provide a way to identify a unique candidate so that the user agent has what it needs to perform de-duplication. Peter From nobody Mon Jun 26 06:28:59 2017 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9367129B82 for ; Mon, 26 Jun 2017 06:28:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j9xv9LToI5Kx for ; Mon, 26 Jun 2017 06:28:56 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7932129B73 for ; Mon, 26 Jun 2017 06:28:55 -0700 (PDT) X-AuditID: c1b4fb2d-563ff70000001f08-7a-59510c1577c0 Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.183.51]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 96.87.07944.51C01595; Mon, 26 Jun 2017 15:28:53 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.25]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.03.0352.000; Mon, 26 Jun 2017 15:28:53 +0200 From: =?iso-8859-1?Q?Ari_Ker=E4nen?= To: ICE WG CC: Peter Thatcher Thread-Topic: Agenda requests for ICE WG at IETF 99 Thread-Index: AQHS7oAnUpr1mpo+qUOdg4faCfxS7Q== Date: Mon, 26 Jun 2017 13:28:52 +0000 Message-ID: <6B4FC4E1-63B8-46E9-8043-5B89DD44DB1A@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrFLMWRmVeSWpSXmKPExsUyM2K7sa4oT2CkwcOV5hbfLtRaXFv+mtWB yWPBplKPJUt+MgUwRXHZpKTmZJalFunbJXBldE3by1Ywh63i/oNdLA2MX1m6GDk5JARMJCas 7mDuYuTiEBI4wijx4EsDI4SzmFHi+4R5zCBVbAL2EpPXfGQEsUUEJCVa/mxkBbGZBTQl7p9c yA5iCwvoSbx49AKqxlii5dxZoDgHkK0nMaMbLMwioCoxYd0SsHJeoJFfZjSA2YwCYhLfT61h ghgpLnHryXwmiOMEJJbsOc8MYYtKvHz8jxXCVpJYdPszVL2exI2pU9ggbGuJl9MXMUPY2hLL Fr5mhtglKHFy5hOWCYwis5CsmIWkfRaS9llI2mchaV/AyLqKUbQ4tbg4N93IWC+1KDO5uDg/ Ty8vtWQTIzBGDm75rbuDcfVrx0OMAhyMSjy8U7kDI4VYE8uKK3MPMUpwMCuJ8Hb8CIgU4k1J rKxKLcqPLyrNSS0+xCjNwaIkzuuw70KEkEB6YklqdmpqQWoRTJaJg1OqgdFjsw//ja71z/dr flhfbLWqdOO37V0S369Oc8o3cFwmv5HD9PfO7BJnjRiZzDzzCUqXRLMsN9XWhl36HX1r1cQN q6eKLE35MEsg0WPNT07dKWvcb68Naf0+UZrRxujjTfZ846S9zyK67uzpPL/s8IJkxsVnDrD9 +SyXtdDFN2NJ6bOal54TVP8osRRnJBpqMRcVJwIAMf2eoY0CAAA= Archived-At: Subject: [Ice] Agenda requests for ICE WG at IETF 99 X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jun 2017 13:28:58 -0000 ICE WG, In the agenda for IETF 99 we have a 2-hour session scheduled on Thursday Ju= ly 20th: https://datatracker.ietf.org/meeting/99/agenda.html If you would like to have a slot at the ICE WG meeting, please let the chai= rs know as soon as possible, but latest Monday 3rd of July. In the face-to-face meeting we will prioritize work that has been already d= iscussed on the mailing list, so please raise open issues on the ICE list a= lready well before the meeting. In your agenda request e-mail please specify the following: - name of the draft (if any) and the presenter - how much time you would like to have - outline of major open issues; what needs to be discussed at the meeting - dependencies to your draft (if any) Thanks, Ari & Peter (ICE WG co-chairs)= From nobody Mon Jun 26 08:49:11 2017 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2501E1289B0 for ; Mon, 26 Jun 2017 08:49:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=stpeter.im header.b=R9krI8sE; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=fJb0ln3g Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H6IIGWJCdYE0 for ; Mon, 26 Jun 2017 08:49:07 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21D271270A7 for ; Mon, 26 Jun 2017 08:49:07 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 751A820C34; Mon, 26 Jun 2017 11:49:06 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute2.internal (MEProxy); Mon, 26 Jun 2017 11:49:06 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stpeter.im; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=K6W/1qxSx1BOjyHXNB pNLdl1Jh0i0YO9FF7nA5rdF1A=; b=R9krI8sEJKonVRVHqCkN5sBzpiAWS24ooZ 9+89EyEAexI8mWtCD6gSNwbIfBbdoFY4O+TiDdanpO2WGB0G6B26lA1MvOm+WBvM ztFPpyaDhOSj8a31trbMAvQ48OwqExaMyMxbVA6V8j8ze3CsZq1BPCeauCrW9QVp F8OKiYVQ50/vSGpVOE2BKVf9fBCMkYsaX5Kfw4e2ULm1wbwgzzCdYBRcLhwU/2pK govMF8nPaJhvSHWId1eX2PVpDpf53nv28seImcUz4ERMRFnxqhbqGTVfvGEt+7BY 43TCz9wRAdYfl2yuE0OL2NBa1qm38qJGuXh06u3ReaVMOsjta2Pg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=K6W/1qxSx1BOjyHXNBpNLdl1Jh0i0YO9FF7nA5rdF1A=; b=fJb0ln3g JhkPvwFZ51vbgQPEWXnKV/X10pdJkQtqru7nPFAzXOEFir+r3KKoULI5jqN8tw5b I3rhMpSGy+zzsQlBvMDAfiHKSN9h8ZDHew5ODZ8TFuNXLZQuhhSf4eJV4PpG+AN5 TTeYB9xRN+0T3yQ7WumVy/j2PM0f0yU5kz4VkJeQGsZs4RRowRJmCVCY5+S3kd0T wpIeYcATJtJzrvMs8PMW76LkoVf0ETIynz1da1co8mn++7ic33ea9PZAfCXKaRAn a8SyMsP5tD1AM9Lb7RN7sR4q2nkZFgyM75jFuJW9fXoN62U1aHZaR6GZPPyIrpBL 3cgBXxemxm1pXQ== X-ME-Sender: X-Sasl-enc: iZiL05YILlA/sC8GqYV1d3gKTpJ9cPuvuM+LLQlztR5/ 1498492146 Received: from aither.local (c-98-245-40-52.hsd1.co.comcast.net [98.245.40.52]) by mail.messagingengine.com (Postfix) with ESMTPA id AF2BA7E755; Mon, 26 Jun 2017 11:49:05 -0400 (EDT) To: =?UTF-8?Q?Ari_Ker=c3=a4nen?= , ICE WG References: <6B4FC4E1-63B8-46E9-8043-5B89DD44DB1A@ericsson.com> Cc: Peter Thatcher From: Peter Saint-Andre Message-ID: <4ca4d161-642f-76c3-48c6-05a72e126df4@stpeter.im> Date: Mon, 26 Jun 2017 09:49:04 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <6B4FC4E1-63B8-46E9-8043-5B89DD44DB1A@ericsson.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Ice] Agenda requests for ICE WG at IETF 99 X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jun 2017 15:49:09 -0000 On 6/26/17 7:28 AM, Ari Keränen wrote: > ICE WG, > > In the agenda for IETF 99 we have a 2-hour session scheduled on > Thursday July 20th: > https://datatracker.ietf.org/meeting/99/agenda.html > > If you would like to have a slot at the ICE WG meeting, please let > the chairs know as soon as possible, but latest Monday 3rd of July. I think we won't need time for the Trickle I-D (I'm planning to submit a revised version in the next day or two incorporating WGLC feedback). Peter From nobody Tue Jun 27 09:00:08 2017 Return-Path: X-Original-To: ice@ietf.org Delivered-To: ice@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 93708129B9B; Tue, 27 Jun 2017 09:00:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ice@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149857920657.31053.9792912095929561449@ietfa.amsl.com> Date: Tue, 27 Jun 2017 09:00:06 -0700 Archived-At: Subject: [Ice] I-D Action: draft-ietf-ice-trickle-12.txt X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jun 2017 16:00:07 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Interactive Connectivity Establishment of the IETF. Title : Trickle ICE: Incremental Provisioning of Candidates for the Interactive Connectivity Establishment (ICE) Protocol Authors : Emil Ivov Eric Rescorla Justin Uberti Peter Saint-Andre Filename : draft-ietf-ice-trickle-12.txt Pages : 31 Date : 2017-06-27 Abstract: This document describes "Trickle ICE", an extension to the Interactive Connectivity Establishment (ICE) protocol that enables ICE agents to send and receive candidates incrementally rather than exchanging complete lists. With such incremental provisioning, ICE agents can begin connectivity checks while they are still gathering candidates and considerably shorten the time necessary for ICE processing to complete. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ice-trickle/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ice-trickle-12 https://datatracker.ietf.org/doc/html/draft-ietf-ice-trickle-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ice-trickle-12 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jun 27 09:01:04 2017 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 715AA129ABD for ; Tue, 27 Jun 2017 09:01:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=stpeter.im header.b=dAPRYjga; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=JKQMupUi Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G1eUuiBxCzkb for ; Tue, 27 Jun 2017 09:00:59 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 441CA126BF3 for ; Tue, 27 Jun 2017 09:00:57 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id AABD921AEE; Tue, 27 Jun 2017 12:00:56 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute2.internal (MEProxy); Tue, 27 Jun 2017 12:00:56 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stpeter.im; h= content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=K28Ts/pAu+wH12g63Z 9Zu0prYfZpt42ND54fJqiNXXQ=; b=dAPRYjgaq4nBbnoe0UDgB4g3YYdd+6URig G7Zt4paSI5qnjCU19Ku4Mh/bFV8Aj1F0girk9tqFD0c1xaRYuF8PVan60stAhmzB E5k/OaXuHcPx2QRmhE1/hwLt4VM8galH45CSme3qh6vFwXQ1ZRUiH99Z+OFJeOSW w9u7CMzZ2sDiOXa1AsavZRPIOFpJgz4pi6jTH/vfbTxX9Xm7Gug48yrRnG0OOqE9 YJS/CVXm1X0NZ9xxs8sobxjjCV/VPpMLcOhWacoG5iM/6VreYnJKxo80XKMFV1yU ZkPgmIyAMUeIHu5Ny7LhA+OmEf+O66E9sf1IclCOGlq67/hfTgWw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=K28Ts/pAu+wH12g63Z9Zu0prYfZpt42ND54fJqiNXXQ=; b=JKQMupUi vUvxfiP7sRQVuNeIcZT16q1xOIY2VsSFstiAjo0TTCrxJX6fgAKHSuUmisHwKPlR q/3cVt2iwEHtDAPTVj+5+zi6EGZKLcrHBWWaLFWuFgzu/zdHVEaDHMOOqflTmKmY 5xMi1+Xi7W9bGGERRVvqZWzTtGvAnbd4Mo6coVhxKoF1O8eylVv2OfGr5LDIVclF +HyPGLeRHqJGtPHH/VeFOvuS8nEb2onpTKatpWmNZUyiQ381cWA08SzFnTz8nyWi 0+hKGyDjjuG71ErllhERzzTLUy7lWoRnwTGZ/U8q/E+2yR1va3yPU+eewy4yjVYl Ox5J2aQG/LX8kA== X-ME-Sender: X-Sasl-enc: QYbncd6uzvSRuF8Z8M8yMFTE7us27vAIpAMwHILRvmtB 1498579256 Received: from aither.local (unknown [76.25.4.24]) by mail.messagingengine.com (Postfix) with ESMTPA id 40D3F24232; Tue, 27 Jun 2017 12:00:56 -0400 (EDT) To: ice@ietf.org References: <149857920657.31053.9792912095929561449@ietfa.amsl.com> From: Peter Saint-Andre Message-ID: <6c6dbeae-e204-5a58-a8a8-14be746fb40a@stpeter.im> Date: Tue, 27 Jun 2017 10:00:55 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <149857920657.31053.9792912095929561449@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Ice] I-D Action: draft-ietf-ice-trickle-12.txt X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jun 2017 16:01:02 -0000 This version addresses feedback received during WGLC. On 6/27/17 10:00 AM, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Interactive Connectivity Establishment of the IETF. > > Title : Trickle ICE: Incremental Provisioning of Candidates for the Interactive Connectivity Establishment (ICE) Protocol > Authors : Emil Ivov > Eric Rescorla > Justin Uberti > Peter Saint-Andre > Filename : draft-ietf-ice-trickle-12.txt > Pages : 31 > Date : 2017-06-27 > > Abstract: > This document describes "Trickle ICE", an extension to the > Interactive Connectivity Establishment (ICE) protocol that enables > ICE agents to send and receive candidates incrementally rather than > exchanging complete lists. With such incremental provisioning, ICE > agents can begin connectivity checks while they are still gathering > candidates and considerably shorten the time necessary for ICE > processing to complete. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-ice-trickle/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-ice-trickle-12 > https://datatracker.ietf.org/doc/html/draft-ietf-ice-trickle-12 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-ice-trickle-12 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > Ice mailing list > Ice@ietf.org > https://www.ietf.org/mailman/listinfo/ice > From nobody Wed Jun 28 00:57:51 2017 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60E6812EB78 for ; Wed, 28 Jun 2017 00:57:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 wiGMX8W1hsWj for ; Wed, 28 Jun 2017 00:57:47 -0700 (PDT) Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com [IPv6:2607:f8b0:400d:c0d::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B243F12EB69 for ; Wed, 28 Jun 2017 00:57:47 -0700 (PDT) Received: by mail-qt0-x22b.google.com with SMTP id f92so43166126qtb.2 for ; Wed, 28 Jun 2017 00:57:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=B1gBAgwvTjU1KcM4zNgN3aK6/v3hrw+HeSltTL48Vkw=; b=geeBN7zyB5uWvFXdRKimILtALpYS/ktzLrDbcm3EMJj9fwHqziBIG15ReOxMBtTwfU xwmv4UiUx++vEF+2kDvCIG71/HRqBNKzIHu3NPV0096YA1WvpiRCmU+eeI6dKkMfoDO6 rvegV93ohby6SMl2s4OrmkuABh2h8v/zM+/6erAv2M8tTXj6mF/3loyXws8/ZZXSwNyf IB0fBAVciw35eoX8XxMAng8ziwObbfkOGed/2Efx7RImXgHJFJyJk0xyFW+I+F8drZuK lVigEDHKEJ/VKcrUqpJdXzqqk4GctVRiMD43lUN74UGGkDQX4fpAE0MbWORVn9b9AYp4 l6UA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=B1gBAgwvTjU1KcM4zNgN3aK6/v3hrw+HeSltTL48Vkw=; b=O6T95fux2ESlZ7wQsh/ZewqSDFofzw6WFddGXikbh1PKxpfcS5XeL/HyYMotANryxw 3ur4azOxoyc09AArwpwsRHwQhUYBQUu1a0walb+duxxtLMRK/Lp4IFi+HcC9368oVjpR iN+tjAah+MSrpn+mGCbUgHXBjHm/zIwTCLdWxMCsa8oq37QxXYsxkl3OlrPuo9gVnH8a IqSVLrlyqkzMzkkJF0AG6yiidzmhKpiXxsw/iYHVRuNGrN/gsYIM9oTsPtlRGwGpRG1L KJ/YerFeYA9NuTH5QCrVyIvemuQlqEjiuKjZ7U9ImYavw9MQ2160tvd+zdgoeEapQmLb 84VA== X-Gm-Message-State: AKS2vOz5qA3xGMIClN3SOne0nDiktbzoTlM1sOuQNARaUSYpBHutlFl3 1WsAV5M0tMUaVkCkEAS+HBBFXXLgtwR4UnZhzg== X-Received: by 10.237.38.33 with SMTP id z30mr11501723qtc.105.1498636666723; Wed, 28 Jun 2017 00:57:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.172.132 with HTTP; Wed, 28 Jun 2017 00:57:46 -0700 (PDT) In-Reply-To: <6c6dbeae-e204-5a58-a8a8-14be746fb40a@stpeter.im> References: <149857920657.31053.9792912095929561449@ietfa.amsl.com> <6c6dbeae-e204-5a58-a8a8-14be746fb40a@stpeter.im> From: Taylor Brandstetter Date: Wed, 28 Jun 2017 00:57:46 -0700 Message-ID: To: Peter Saint-Andre Cc: ice@ietf.org Content-Type: multipart/alternative; boundary="94eb2c12293c2b571e0553008a4e" Archived-At: Subject: Re: [Ice] I-D Action: draft-ietf-ice-trickle-12.txt X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2017 07:57:50 -0000 --94eb2c12293c2b571e0553008a4e Content-Type: text/plain; charset="UTF-8" > > Then, as the checks proceed (see Section 6.2.5.4 of [rfc5245bis ]), > for each pair that enters the Succeeded state (denoted here by "S"), > the agent will unfreeze all pairs for all media streams with the same > foundation (e.g., if the pair in column 1, row 1 succeeds then the > agent will unfreeze the pair in column 1, row 2). > > Sorry to keep nitpicking about this section... But since this changed from "the same media stream" to "all media streams", "pair in column 1, row 2" should be replaced with "pairs in column 1, rows 2, 3 and 4". > ICE also specifies > that, if all the pairs in a media stream for one foundation are > unfrozen (e.g., column 1, rows 1 and 2 representing both components > for the audio stream), then all of the candidate pairs in the entire > column are unfrozen (e.g., column 1, rows 3 and 4). > > This isn't true any more. RFC5245bis appears to only have two rules about unfreezing now: 1. If a pair succeeds, everything with the same foundation is unfrozen. 2. If Ta fires for a checklist, and its whole row is frozen, every cell that's part of a column that's completely frozen is unfrozen (enforced by section 5.1.4.2, step 2). This is still pretty weird, but at least not as complex as the "for each component" rule before. #2 isn't called out. Should it be? On Tue, Jun 27, 2017 at 9:00 AM, Peter Saint-Andre wrote: > This version addresses feedback received during WGLC. > > On 6/27/17 10:00 AM, internet-drafts@ietf.org wrote: > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > This draft is a work item of the Interactive Connectivity Establishment > of the IETF. > > > > Title : Trickle ICE: Incremental Provisioning of > Candidates for the Interactive Connectivity Establishment (ICE) Protocol > > Authors : Emil Ivov > > Eric Rescorla > > Justin Uberti > > Peter Saint-Andre > > Filename : draft-ietf-ice-trickle-12.txt > > Pages : 31 > > Date : 2017-06-27 > > > > Abstract: > > This document describes "Trickle ICE", an extension to the > > Interactive Connectivity Establishment (ICE) protocol that enables > > ICE agents to send and receive candidates incrementally rather than > > exchanging complete lists. With such incremental provisioning, ICE > > agents can begin connectivity checks while they are still gathering > > candidates and considerably shorten the time necessary for ICE > > processing to complete. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-ice-trickle/ > > > > There are also htmlized versions available at: > > https://tools.ietf.org/html/draft-ietf-ice-trickle-12 > > https://datatracker.ietf.org/doc/html/draft-ietf-ice-trickle-12 > > > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=draft-ietf-ice-trickle-12 > > > > > > Please note that it may take a couple of minutes from the time of > submission > > until the htmlized version and diff are available at tools.ietf.org. > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > Ice mailing list > > Ice@ietf.org > > https://www.ietf.org/mailman/listinfo/ice > > > > _______________________________________________ > Ice mailing list > Ice@ietf.org > https://www.ietf.org/mailman/listinfo/ice > --94eb2c12293c2b571e0553008a4e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 
   Then, as the checks proceed (see Section 6.2.5=
.4 of [rfc5245bis]),
   for each pair that enters the Succeeded state (denoted here by "S&q=
uot;),
   the agent will unfreeze all pairs for all media streams with the same
   foundation (e.g., if the pair in column 1, row 1 succeeds then the
   agent will unfreeze the pair in column 1, row 2).

Sorr= y to keep nitpicking about this section... But since this changed from &quo= t;the same media stream" to "all media streams", "pair = in column 1, row 2" should be replaced with "pairs in column 1, r= ows 2, 3 and 4".
=C2=A0
   ICE also specif=
ies
   that, if all the pairs in a media stream for one foundation are
   unfrozen (e.g., column 1, rows 1 and 2 representing both components
   for the audio stream), then all of the candidate pairs in the entire
   column are unfrozen (e.g., column 1, rows 3 and 4).

This isn't true any more. RFC5245bis appears to only = have two rules about unfreezing now:
  1. If a pair succeeds, = everything with the same foundation is unfrozen.
  2. If Ta fires for a = checklist, and its whole row is frozen, every cell that's part of a col= umn that's completely frozen is unfrozen (enforced by section 5.1.4.2, = step 2). This is still pretty weird, but at least not as complex as the &qu= ot;for each component" rule before.
#2 isn't called = out. Should it be?


On Tue, Jun 27, 2017 at 9:00 AM, Peter Sa= int-Andre <stpeter@stpeter.im> wrote:
This version addresses feedback received during WGLC.

On 6/27/17 10:00 AM, internet-d= rafts@ietf.org wrote:
>
> A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories.
> This draft is a work item of the Interactive Connectivity Establishmen= t of the IETF.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0: Trickle ICE: Incremental Provisioning of Candidates for the Int= eractive Connectivity Establishment (ICE) Protocol
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0: Emil Ivov
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0Eric Rescorla
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0Justin 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 =C2=A0Peter Saint-Andre
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-= ietf-ice-trickle-12.txt
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0: 31
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 : 2017-06-27
>
> Abstract:
>=C2=A0 =C2=A0 This document describes "Trickle ICE", an exten= sion to the
>=C2=A0 =C2=A0 Interactive Connectivity Establishment (ICE) protocol tha= t enables
>=C2=A0 =C2=A0 ICE agents to send and receive candidates incrementally r= ather than
>=C2=A0 =C2=A0 exchanging complete lists.=C2=A0 With such incremental pr= ovisioning, ICE
>=C2=A0 =C2=A0 agents can begin connectivity checks while they are still= gathering
>=C2=A0 =C2=A0 candidates and considerably shorten the time necessary fo= r ICE
>=C2=A0 =C2=A0 processing to complete.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/d= raft-ietf-ice-trickle/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ie= tf-ice-trickle-12
> https://datatracker.ietf.org/doc/html/draft-ietf-ice-trickle-12
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?= url2=3Ddraft-ietf-ice-trickle-12
>
>
> Please note that it may take a couple of minutes from the time of subm= ission
> 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/
>
> _______________________________________________
> Ice mailing list
> Ice@ietf.org
> https://www.ietf.org/mailman/listinfo/ice
>

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

--94eb2c12293c2b571e0553008a4e-- From nobody Wed Jun 28 10:08:19 2017 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A7FB129A9F for ; Wed, 28 Jun 2017 10:08:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mRykQCmlbvm0 for ; Wed, 28 Jun 2017 10:08:16 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A20F8126B7E for ; Wed, 28 Jun 2017 10:08:15 -0700 (PDT) X-AuditID: c1b4fb3a-bea2a9c000001b2f-93-5953e27d17ab Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.183.60]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id A8.80.06959.D72E3595; Wed, 28 Jun 2017 19:08:13 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.25]) by ESESSHC014.ericsson.se ([153.88.183.60]) with mapi id 14.03.0352.000; Wed, 28 Jun 2017 19:08:08 +0200 From: Christer Holmberg To: Taylor Brandstetter , Peter Saint-Andre CC: "ice@ietf.org" Thread-Topic: [Ice] I-D Action: draft-ietf-ice-trickle-12.txt Thread-Index: AQHS7150t+qE8lQMSkOqjp9ccw86DKI4vNmAgAELVwCAALoncA== Date: Wed, 28 Jun 2017 17:08:08 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4CC26102@ESESSMB109.ericsson.se> References: <149857920657.31053.9792912095929561449@ietfa.amsl.com> <6c6dbeae-e204-5a58-a8a8-14be746fb40a@stpeter.im> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrPLMWRmVeSWpSXmKPExsUyM2K7jW7to+BIg0XPjSwur3jIavHtQq3F sT39zA7MHgs2lXosWfKTyWPunhfMAcxRXDYpqTmZZalF+nYJXBnHv15lLPilUPH3UANrA2OP QhcjJ4eEgInE9hlzGEFsIYEjjBJPj8Z3MXIB2YsZJaas3cDUxcjBwSZgIdH9TxvEFBEIlzi/ NgfEZBZQlHi5Vw2kU1jARqKlfTsriC0iYCux5MVLdgjbSaKtaT6YzSKgKnHgyTMmEJtXwFdi 6sEFzBBb9zFKPJhmBGJzCgRKdC04ATaHUUBM4vupNWD1zALiEreezGeCuFhAYsme88wQtqjE y8f/WCFsJYnGJU9YIU7TlFi/Sx+iVVFiSvdDdoi1ghInZz5hmcAoOgvJ1FkIHbOQdMxC0rGA kWUVo2hxanFxbrqRkV5qUWZycXF+nl5easkmRmC0HNzy22oH48HnjocYBTgYlXh4fbcHRwqx JpYVV+YeYpTgYFYS4a04CxTiTUmsrEotyo8vKs1JLT7EKM3BoiTO67DvQoSQQHpiSWp2ampB ahFMlomDU6qB0eHmmyvNldZra7ZofJ0/XejcnoUbZmb1d6cFlT1+x5BS/mR3eeGjjYdXn3xx Pb2F6bGZVuv0jR9rNxiZ5b88Ku+wW4xvcfuvNTuDGfjvPgkSstAOWHXd5/90k6jbk0pmilz8 PDvyn7Pw+cITPKqd8ou/iDgWhldZHhF8emLmu58/DjmphHbteq/EUpyRaKjFXFScCAAuC8R4 kgIAAA== Archived-At: Subject: Re: [Ice] I-D Action: draft-ietf-ice-trickle-12.txt X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2017 17:08:18 -0000 SGksDQoNCuKApg0KDQo+VGhpcyBpc24ndCB0cnVlIGFueSBtb3JlLiBSRkM1MjQ1YmlzIGFwcGVh cnMgdG8gb25seSBoYXZlIHR3byBydWxlcyBhYm91dCB1bmZyZWV6aW5nIG5vdzoNCj4gMS4gSWYg YSBwYWlyIHN1Y2NlZWRzLCBldmVyeXRoaW5nIHdpdGggdGhlIHNhbWUgZm91bmRhdGlvbiBpcyB1 bmZyb3plbi4NCj4gMi4gSWYgVGEgZmlyZXMgZm9yIGEgY2hlY2tsaXN0LCBhbmQgaXRzIHdob2xl IHJvdyBpcyBmcm96ZW4sIGV2ZXJ5IGNlbGwgdGhhdCdzIHBhcnQgb2YgYSBjb2x1bW4gdGhhdCdz IGNvbXBsZXRlbHkgDQo+IGZyb3plbiBpcyB1bmZyb3plbiAoZW5mb3JjZWQgYnkgc2VjdGlvbiA1 LjEuNC4yLCBzdGVwIDIpLg0KDQpOb3RlIHRoYXQgMikgb25seSBoYXBwZW5zIGlmIHRoZXJlIGlz IG5vIHBhaXIocykgZm9yIHRoZSBzYW1lIGZvdW5kYXRpb24gaW4gV2FpdGluZy9Jbi1Qcm9ncmVz cyBzdGF0ZS4NCg0KTWF5YmUgdGhhdCdzIHdoYXQgeW91IG1lYW50LCBidXQgaW4geW91ciByZXBs eSBJIHNvdW5kZWQgbGlrZSBpdCBhbHdheXMgaGFwcGVucyBpZiB0aGUgd2hvbGUgcm93IGlzIGZy b3plbiA6KQ0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQoNCiBUaGlzIGlzIHN0aWxsIHByZXR0 eSB3ZWlyZCwgYnV0IGF0IGxlYXN0IG5vdCBhcyBjb21wbGV4IA0KPiBhcyB0aGUgImZvciBlYWNo IGNvbXBvbmVudCIgcnVsZSBiZWZvcmUuDQojMiBpc24ndCBjYWxsZWQgb3V0LiBTaG91bGQgaXQg YmU/DQoNCg0KT24gVHVlLCBKdW4gMjcsIDIwMTcgYXQgOTowMCBBTSwgUGV0ZXIgU2FpbnQtQW5k cmUgPHN0cGV0ZXJAc3RwZXRlci5pbT4gd3JvdGU6DQpUaGlzIHZlcnNpb24gYWRkcmVzc2VzIGZl ZWRiYWNrIHJlY2VpdmVkIGR1cmluZyBXR0xDLg0KDQpPbiA2LzI3LzE3IDEwOjAwIEFNLCBpbnRl cm5ldC1kcmFmdHNAaWV0Zi5vcmcgd3JvdGU6DQo+DQo+IEEgTmV3IEludGVybmV0LURyYWZ0IGlz IGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cyBkaXJlY3Rvcmllcy4N Cj4gVGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgSW50ZXJhY3RpdmUgQ29ubmVjdGl2 aXR5IEVzdGFibGlzaG1lbnQgb2YgdGhlIElFVEYuDQo+DQo+wqAgwqAgwqAgwqAgwqBUaXRsZcKg IMKgIMKgIMKgIMKgIMKgOiBUcmlja2xlIElDRTogSW5jcmVtZW50YWwgUHJvdmlzaW9uaW5nIG9m IENhbmRpZGF0ZXMgZm9yIHRoZSBJbnRlcmFjdGl2ZSBDb25uZWN0aXZpdHkgRXN0YWJsaXNobWVu dCAoSUNFKSBQcm90b2NvbA0KPsKgIMKgIMKgIMKgIMKgQXV0aG9yc8KgIMKgIMKgIMKgIMKgOiBF bWlsIEl2b3YNCj7CoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoEVyaWMg UmVzY29ybGENCj7CoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoEp1c3Rp biBVYmVydGkNCj7CoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoFBldGVy IFNhaW50LUFuZHJlDQo+wqAgwqAgwqAgwqBGaWxlbmFtZcKgIMKgIMKgIMKgIDogZHJhZnQtaWV0 Zi1pY2UtdHJpY2tsZS0xMi50eHQNCj7CoCDCoCDCoCDCoFBhZ2VzwqAgwqAgwqAgwqAgwqAgwqA6 IDMxDQo+wqAgwqAgwqAgwqBEYXRlwqAgwqAgwqAgwqAgwqAgwqAgOiAyMDE3LTA2LTI3DQo+DQo+ IEFic3RyYWN0Og0KPsKgIMKgIFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzICJUcmlja2xlIElDRSIs IGFuIGV4dGVuc2lvbiB0byB0aGUNCj7CoCDCoCBJbnRlcmFjdGl2ZSBDb25uZWN0aXZpdHkgRXN0 YWJsaXNobWVudCAoSUNFKSBwcm90b2NvbCB0aGF0IGVuYWJsZXMNCj7CoCDCoCBJQ0UgYWdlbnRz IHRvIHNlbmQgYW5kIHJlY2VpdmUgY2FuZGlkYXRlcyBpbmNyZW1lbnRhbGx5IHJhdGhlciB0aGFu DQo+wqAgwqAgZXhjaGFuZ2luZyBjb21wbGV0ZSBsaXN0cy7CoCBXaXRoIHN1Y2ggaW5jcmVtZW50 YWwgcHJvdmlzaW9uaW5nLCBJQ0UNCj7CoCDCoCBhZ2VudHMgY2FuIGJlZ2luIGNvbm5lY3Rpdml0 eSBjaGVja3Mgd2hpbGUgdGhleSBhcmUgc3RpbGwgZ2F0aGVyaW5nDQo+wqAgwqAgY2FuZGlkYXRl cyBhbmQgY29uc2lkZXJhYmx5IHNob3J0ZW4gdGhlIHRpbWUgbmVjZXNzYXJ5IGZvciBJQ0UNCj7C oCDCoCBwcm9jZXNzaW5nIHRvIGNvbXBsZXRlLg0KPg0KPg0KPiBUaGUgSUVURiBkYXRhdHJhY2tl ciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBpczoNCj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1pY2UtdHJpY2tsZS8NCj4NCj4gVGhlcmUgYXJlIGFsc28g aHRtbGl6ZWQgdmVyc2lvbnMgYXZhaWxhYmxlIGF0Og0KPiBodHRwczovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtaWV0Zi1pY2UtdHJpY2tsZS0xMg0KPiBodHRwczovL2RhdGF0cmFja2VyLmll dGYub3JnL2RvYy9odG1sL2RyYWZ0LWlldGYtaWNlLXRyaWNrbGUtMTINCj4NCj4gQSBkaWZmIGZy b20gdGhlIHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0Og0KPiBodHRwczovL3d3dy5p ZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1pY2UtdHJpY2tsZS0xMg0KPg0KPg0KPiBQ bGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUg dGltZSBvZiBzdWJtaXNzaW9uDQo+IHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZm IGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQo+DQo+IEludGVybmV0LURyYWZ0cyBh cmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDoNCj4gZnRwOi8vZnRwLmlldGYu b3JnL2ludGVybmV0LWRyYWZ0cy8NCj4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4gSWNlIG1haWxpbmcgbGlzdA0KPiBJY2VAaWV0Zi5vcmcNCj4g aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pY2UNCj4NCg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkljZSBtYWlsaW5nIGxpc3QN CkljZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pY2UN Cg0K From nobody Wed Jun 28 16:00:53 2017 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2FCB1298BA for ; Wed, 28 Jun 2017 16:00:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=stpeter.im header.b=n5jtloUj; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Qp5fDeVM Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PodG5seFHMyw for ; Wed, 28 Jun 2017 16:00:50 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE4F4129B1D for ; Wed, 28 Jun 2017 16:00:49 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 4E38721E59; Wed, 28 Jun 2017 19:00:49 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute2.internal (MEProxy); Wed, 28 Jun 2017 19:00:49 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stpeter.im; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=H0HWhat6uj3uwrrlCO yWahBR0O4D4l0Hwl7wGSDWIoU=; b=n5jtloUjCSW6Lin/KrH03b6bYRTmZHQfBf +D2EQ7EWwFbcEslSYB2H3I4rH6e/t2dZOdq7OE+uO5Wxjud+XUf0Uh7CTgWY3ojT 85Kd0ilNu/vK2JUoLpGw9gSbqNO9Uc4YTw7GB+lpeTQTf1fqUW4MMlg/yUw1tyIu YS7rWXrhg/02z9DoNRlWOoOoiq6di9EGxejJAxjs15PvO7R6Dqre6Ul/Fm3U2m7t zw5k3zTdkEAXEW6mSpVfspEx5P+PrGskT8fuPEGjjpjO+ur4Zt582Gqeq2hr0oAk w1mXEPWMJPgUecmU0TK08Hi+mK0f1CqAbi0piIiJ+3WZavm2H6FQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=H0HWhat6uj3uwrrlCOyWahBR0O4D4l0Hwl7wGSDWIoU=; b=Qp5fDeVM 4xGlWqQEjeaudcntYY5qSBXN+Xhw05iuIuv2mgPYVYKNCsd47U4rfSKsKtpYyTor jYeOlx5Dc7J512F20sriXnFKmnSePCAeR9Ey4w+EDGCCWZRx2M+xbhY4dS1HGRe/ lZWIluyQfxGSZEqnUOalzjF9/KI/syElbjSaCS49YzlraLmzbH31hzHDZDwV5Z6w D4zyc3Or5ax5wVqmDHIXRMQfpvdNKKe7jLpd7+au+9yft4pv0vBwolqqHHWvAFWG /F+Is1M1WaNs0NfCKh/weWS/kFUE4lR3YnRsvv+wyDELDCGRkSHfdsA8/DCFc+4U Ka1cxpfVhDtfiw== X-ME-Sender: X-Sasl-enc: Dny01rTgzjt4VjDOmCSXDx80extk0ZpiXDTSijKmGK1e 1498690849 Received: from aither.local (unknown [76.25.4.24]) by mail.messagingengine.com (Postfix) with ESMTPA id CC6F62436B; Wed, 28 Jun 2017 19:00:48 -0400 (EDT) To: Taylor Brandstetter References: <149857920657.31053.9792912095929561449@ietfa.amsl.com> <6c6dbeae-e204-5a58-a8a8-14be746fb40a@stpeter.im> Cc: ice@ietf.org From: Peter Saint-Andre Message-ID: <9ecc8e18-79d6-6d4b-ac90-3f87f939cdb8@stpeter.im> Date: Wed, 28 Jun 2017 17:00:47 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Ice] I-D Action: draft-ietf-ice-trickle-12.txt X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2017 23:00:52 -0000 On 6/28/17 1:57 AM, Taylor Brandstetter wrote: > Then, as the checks proceed (see Section 6.2.5.4 of [rfc5245bis > ]), > for each pair that enters the Succeeded state (denoted here by "S"), > the agent will unfreeze all pairs for all media streams with the same > foundation (e.g., if the pair in column 1, row 1 succeeds then the > agent will unfreeze the pair in column 1, row 2). > > > Sorry to keep nitpicking about this section... But since this changed > from "the same media stream" to "all media streams", "pair in column 1, > row 2" should be replaced with "pairs in column 1, rows 2, 3 and 4". Good catch, will fix. > ICE also specifies > that, if all the pairs in a media stream for one foundation are > unfrozen (e.g., column 1, rows 1 and 2 representing both components > for the audio stream), then all of the candidate pairs in the entire > column are unfrozen (e.g., column 1, rows 3 and 4). > > > This isn't true any more. RFC5245bis appears to only have two rules > about unfreezing now: > > 1. If a pair succeeds, everything with the same foundation is unfrozen. > 2. If Ta fires for a checklist, and its whole row is frozen, every cell > that's part of a column that's completely frozen is unfrozen > (enforced by section 5.1.4.2, step 2). This is still pretty weird, > but at least not as complex as the "for each component" rule before. > > #2 isn't called out. Should it be? I'll let you and Christer decide on what's right here. ;-) Peter From nobody Wed Jun 28 22:17:56 2017 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 537F2127A91 for ; Wed, 28 Jun 2017 22:17:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 BZo-_eHbQKj9 for ; Wed, 28 Jun 2017 22:17:51 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1044C127867 for ; Wed, 28 Jun 2017 22:17:50 -0700 (PDT) X-AuditID: c1b4fb3a-81bff70000001b2f-22-59548d7c1384 Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.183.39]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 1C.15.06959.C7D84595; Thu, 29 Jun 2017 07:17:48 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.25]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.03.0352.000; Thu, 29 Jun 2017 07:17:47 +0200 From: Christer Holmberg To: Peter Saint-Andre CC: Taylor Brandstetter , "ice@ietf.org" Thread-Topic: [Ice] I-D Action: draft-ietf-ice-trickle-12.txt Thread-Index: AQHS7150t+qE8lQMSkOqjp9ccw86DKI4vNmAgAELVwCAAPxNgIAAaVIA Date: Thu, 29 Jun 2017 05:17:47 +0000 Message-ID: <1ECCF540-3D1F-4032-A783-381E2B16D929@ericsson.com> References: <149857920657.31053.9792912095929561449@ietfa.amsl.com> <6c6dbeae-e204-5a58-a8a8-14be746fb40a@stpeter.im> <9ecc8e18-79d6-6d4b-ac90-3f87f939cdb8@stpeter.im> In-Reply-To: <9ecc8e18-79d6-6d4b-ac90-3f87f939cdb8@stpeter.im> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Content-Type: multipart/signed; boundary="Apple-Mail-DCB780C2-2F26-48E1-B072-0FE5299937B8"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrFIsWRmVeSWpSXmKPExsUyM2K7um5Nb0ikwYJ7KhaXVzxktfh2odbi 2J5+ZgdmjwWbSj2WLPnJ5DF3zwvmAOYoLpuU1JzMstQifbsEroxbey6yFFz0qbh6cTdLA2O/ excjJ4eEgInEzpkfWLsYuTiEBI4wSpyY948ZwlnMKHFr/jLGLkYODjYBC4nuf9ogDSICWhKX rvWxg9jMAj4SV95tBbOFBWwkzvZvZoaosZVY8uIlO4TtJrF78jY2EJtFQFXi5unNLCA2r4C9 xPb1+1kgdn1ilLi+ajFYglPATmL69eesIDajgJjE91NrmCCWiUvcejKfCeJqEYmHF0+zQdii Ei8f/wP7gFlgMqPEsxWz2CA2CEqcnPmEZQKj8Cwk/bOQ1c1CUjcL6FFmAR2JyQsZIeq1JZYt fM0MYVtLzPh1kA3CNpV4ffQjVI2ixJTuh+wLGDlWMYoWpxYX56YbGemlFmUmFxfn5+nlpZZs YgTG2sEtv612MB587niIUYCDUYmH93JPSKQQa2JZcWXuIUYVoDmPNqy+wCjFkpefl6okwuve AJTmTUmsrEotyo8vKs1JLT7EKM3BoiTO67DvQoSQQHpiSWp2ampBahFMlomDU6qBsbSwNn9q kurEaQJXfq2InPOoqUMguvPzthlbH+Vy28oyFh7d+iZs1f4Fr29r3Xh8+etaP7kyV2fXhWzT hcMdHJl/N3G5T/2/Nvl2gYrJ7sAK7zVvkz5mMYo+n9Qlukn51AdJpsenRf5OnlORajVZl/2k n5jxm1U79wucdFu1R07YbCJXTZrGbyWW4oxEQy3mouJEALKDzk+9AgAA Archived-At: Subject: Re: [Ice] I-D Action: draft-ietf-ice-trickle-12.txt X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jun 2017 05:17:53 -0000 --Apple-Mail-DCB780C2-2F26-48E1-B072-0FE5299937B8 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Hi, In general, when the spec says "ICE specifies", it would be good with a refe= rence to the section in 5245bis. Regards, Christer Sent from my iPhone > On 29 Jun 2017, at 1.00, Peter Saint-Andre wrote: >=20 >> On 6/28/17 1:57 AM, Taylor Brandstetter wrote: >> Then, as the checks proceed (see Section 6.2.5.4 of [rfc5245bis >> = ]), >> for each pair that enters the Succeeded state (denoted here by "S")= , >> the agent will unfreeze all pairs for all media streams with the sa= me >> foundation (e.g., if the pair in column 1, row 1 succeeds then the >> agent will unfreeze the pair in column 1, row 2). >>=20 >>=20 >> Sorry to keep nitpicking about this section... But since this changed >> from "the same media stream" to "all media streams", "pair in column 1, >> row 2" should be replaced with "pairs in column 1, rows 2, 3 and 4". >=20 > Good catch, will fix. >=20 >> ICE also specifies >> that, if all the pairs in a media stream for one foundation are >> unfrozen (e.g., column 1, rows 1 and 2 representing both components= >> for the audio stream), then all of the candidate pairs in the entir= e >> column are unfrozen (e.g., column 1, rows 3 and 4). >>=20 >>=20 >> This isn't true any more. RFC5245bis appears to only have two rules >> about unfreezing now: >>=20 >> 1. If a pair succeeds, everything with the same foundation is unfrozen. >> 2. If Ta fires for a checklist, and its whole row is frozen, every cell >> that's part of a column that's completely frozen is unfrozen >> (enforced by section 5.1.4.2, step 2). This is still pretty weird, >> but at least not as complex as the "for each component" rule before. >>=20 >> #2 isn't called out. Should it be? >=20 > I'll let you and Christer decide on what's right here. ;-) >=20 > Peter >=20 >=20 > _______________________________________________ > Ice mailing list > Ice@ietf.org > https://www.ietf.org/mailman/listinfo/ice --Apple-Mail-DCB780C2-2F26-48E1-B072-0FE5299937B8 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIR8zCCBTgw ggMgoAMCAQICEQCVvhag9y5G8Xs5gnL6i82WMA0GCSqGSIb3DQEBBQUAMDcxFDASBgNVBAoMC1Rl bGlhU29uZXJhMR8wHQYDVQQDDBZUZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTA3MTAxODEyMDA1 MFoXDTMyMTAxODEyMDA1MFowNzEUMBIGA1UECgwLVGVsaWFTb25lcmExHzAdBgNVBAMMFlRlbGlh U29uZXJhIFJvb3QgQ0EgdjEwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDCvusn8CGj 82kmVX6dxVUWkVz97yG/U4B6LdKRjGMx8Owk8MOl0nJ8EG30N7fl5nx56oy1gouuSLasANxldewq TV/Bh/UgZSuBqEc+iSOVMBaQf+hXB0jnGa6/RWexNxsGKv7e+ax9g/teuuSPl2e+S46NZAdXOFVp NDY9E0jvT+LTZh6kzxq3XjYz1LQGvRgB/XeEUABF9Yxd6CO8fv414e1Qe6kwjRnTCY5oZ12/PJcY U7spYsXKXnLBx5bU2y2gtB9pA+zq4lDxDDzwrPNTLfAc9e1sOTlzgBbIUrAjzeA+3N08R6C7NYri mGiLvuW/cu7S+qXtEu38mBipJnbcKEsQIBzTfxZ3Le1vgPdJu1MFu11ox9TIdRY/iVqL9xdH1Ezx 0ol5Pk09mKhh3joe0vheA+DByRyM041N05U2szdfY2ObMxTwLSZrU3yJjDLCbuw9IQA5yaFo4lCD LrA6K/M2oKwv5G9hwlEJOT6LU7m7Z9rcU7l2WTadQ+Ug4D0yYIUiUbfHM7vdFS+keKYHe4FGNgSG 3Xk1x5UsO7CjFzXlcx+0XFnv2uoQZXt60H+fs7QqNztwi5tbuSu37LJREpdTKVrU8BIQ3E8CuxKS L2LUP2lDfA3W/Fh1AYidWBZL3rqQ/0cBiQZq9l+ykGqzAqYCiL+zR34q2dX6aHg1TQIDAQABoz8w PTAPBgNVHRMBAf8EBTADAQH/MAsGA1UdDwQEAwIBBjAdBgNVHQ4EFgQU8I9ZOACz9Y+algzV6/p7 qhfoExIwDQYJKoZIhvcNAQEFBQADggIBAL7kXGJOJPQMCP/w0wxo5JNJIj9EJ2+7bd6DZs6ozA38 9ZoG5XcUkeudQXuZKoTl//whwV3w5B9Xt3WpoV8CJv/Xx/dO3k/49xxGwHpPQCwiNfAZsdBrZyyw qODAQDc19oRcXOOvQnj+p8kNUOoNhHb2Ue+DU8Z6/w5WSS6PetYM5idU400KYHJizZEH1qW/yJlr 7cQZ5qtMETjFbzHibknIP3aAJgMmKeA29vYgU+MXcDQXnWNoHmvsw02GuBMwL11GDUdD1RuqWQ65 XI0GSK10h1/H/DFUQRPixyEOnuAeDeHAe0OFkMWKWMZlCnhX8sYjDwHZIEveD/uShXUqXHONbXsl kcruRa4GSwDM07FZUNo6iDspQ0ZelytUzlNvjUrnlvq/cQ5Ci3z9KKDQSMraxIFMu6JzkybI6wzW Joi2wCTPu71b63V96QiOhjMseXcJaaWJ/LNwkId2j9Miu0LOvXMLICYq0Js9cB4kbM2HdqkXlrfP DZL7jhipmEnRnv5gRHIhuRntwvUx8TlIiJAkdVQWrc70+GkUZDn7o7i6cEDHJxy/xFZT+mNl0PMc Dhb1a4ZYTRjU5A2OpZ1bkdx2JFA/xir72bectdbm0NnoGYsVcUitt+rYWYjUkL8Ws9nprFlhVMgc usrByuG5IEyPOpOJpaDMv9P2daR1lm1WMIIF+TCCA+GgAwIBAgIQMQ1yPcGTNYDzhYWhrkFQyDAN BgkqhkiG9w0BAQUFADA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwg SW5kaXZpZHVhbCBDQSB2MjAeFw0xNDExMDQxMjI4MTlaFw0xNzExMDQxMjI4MThaMG8xETAPBgNV BAoMCEVyaWNzc29uMRowGAYDVQQDDBFDaHJpc3RlciBIb2xtYmVyZzEtMCsGCSqGSIb3DQEJARYe Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tMQ8wDQYDVQQFEwZMTUZDSEgwggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQCMb7fHWIV9CIFYYov86NR/6ibdVV0I+ZqVLE21zQB7otFv 6DTKlVXE7iiC4HCvMhlGkg3/qFmAhAti5Z1Z7+5eEMEIP5JJEZ7fMm6BME33Bkdgg4EfJrq4FUG2 8Hw2//0qx3jZWvK2W751AmEuUJ5nkZ6F00GnzJmOhbveadC8E5keqwow9ria0/WazHiK3wxzjban oQaZIA+oCKj5YyCv8cCTaSk4pEAbXwxthJ97BaZPahsnb4EZEP08gxR5IE9NRi47Eqh6LtBjiWpa B42EmCEBxc2uIQ87tlJ0e2SvCo74rqxndXtUeaWauMjjt4DnhJdiXZY244D5J1gWssRFAgMBAAGj ggHEMIIBwDBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vY3JsLnRydXN0LnRlbGlhLmNvbS9lcmlj c3Nvbm5saW5kaXZpZHVhbGNhdjIuY3JsMIGCBggrBgEFBQcBAQR2MHQwKAYIKwYBBQUHMAGGHGh0 dHA6Ly9vY3NwMi50cnVzdC50ZWxpYS5jb20wSAYIKwYBBQUHMAKGPGh0dHA6Ly9jYS50cnVzdC50 ZWxpYXNvbmVyYS5jb20vZXJpY3Nzb25ubGluZGl2aWR1YWxjYXYyLmNlcjApBgNVHREEIjAggR5j aHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20wVQYDVR0gBE4wTDBKBgwrBgEEAYIPAgMBARIw OjA4BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS9D UFMwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMB0GA1UdDgQWBBRUo03/DrRAW2xpMmhN 2uGkvDgx6jAfBgNVHSMEGDAWgBSxDcrURrevhgLDL28Gyg52cX9LNzAOBgNVHQ8BAf8EBAMCBaAw DQYJKoZIhvcNAQEFBQADggIBALbwqG5inhl/xPxsuQWcH7GOUZIPAw0JlKltVQ/TlsF7ig0J1iyz ao6GsXItJ9H3WZPrCy5EQchJm7qcn2kKX8OGb+Yr53FisLR2gx+qkrQMDOdix9Was0cvIjDWjAQn EZbxz/a+dzdAP0TrwNvD8282bIy0fCt/3uoBfzMnvQG+4wG018bDunc+NCj1FkSKkSRb9fP2Z2li 65pfJcxtGIfb5zsXJZG4Gtbe0/hxlj3NccjB/zVPO7PQ+lnWmxtOiJQ2loA+62vQreUQr328XK4I HFnoU+zXiVfUN2urvvirQH7Ha70TBMa20J8Nn2aEvY6QYMEQJhAiVmNTiv4EGGv5heX5vb8yaj7p r4YIvb6D0r+pwpvfEE8YhAEWJgCZP7k5zQwhrpuSF/s+wEruXo59sq9bOCefghktc5fwDu8ved98 cifRPUnuT/c5slJJ8LjFn8d+LnGklUdFA9kLjIJVVx+TM4D/OTaRG+mPFbY2pTyR0V84PG7HLeku pNsFzcme7IBkQ+1zkb9hjz6pyiodf6rh7ph+8XHWNgzbC5PdGCANg8fVWrxqqOoEzvcUcPMy6XXJ s0JWhWas8mJdHq2kGDDEpA7BbBatmtEqziXRnYGJeQK3eMDXXtmOeBSA4y7YZ47y+CxvbknSQ5dy ghwkEq+a7ORPGVjsjtWJYJ6dMIIGtjCCBJ6gAwIBAgIRAKAMy8ybmZjs4jpw9HzBwFkwDQYJKoZI hvcNAQEFBQAwNzEUMBIGA1UECgwLVGVsaWFTb25lcmExHzAdBgNVBAMMFlRlbGlhU29uZXJhIFJv b3QgQ0EgdjEwHhcNMTQwNTI3MDc0NjIxWhcNMjQwNTI3MDc0NjIxWjA6MREwDwYDVQQKDAhFcmlj c3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MjCCAiIwDQYJKoZIhvcN AQEBBQADggIPADCCAgoCggIBANq6U+tfSJZTn4k46qN13HgaeXXsMmGSWShc6A5IEyFboXMZW3lF Hso+/6uO3ZilvB2ipZJhrhU+RL/va+5Chay/PZq9ZZeE9N03OsHfOzlwk7uwojJ34tHLiX/yQori I+b5DXxfIYXTFO5zlZLdaIxJwlLEQp0g4/zF6EGtodlpusaH07FAcLiIEeTMPRgXcn+8GoFOvtuV HNh/WHePlrupUgcI9/P54ITXvmZF6xcNBEjsu8yJm1VqqK0GXSgAmInJ4Ga8S6ME2wgSBRDolxAU bmfLQRrMvLC/tyXBvuLO8uChdzpIWt3QPtMYm2R2V1Um0zANhenIUwYCKNPq5/yHaS48jCsOBAU0 TIhBnirnZmlEbC6ALqwzGAcQMaMD8LFf1oLlWLUQxEmI4YXqBXdP5XnIcMdIEF5BtUBebzBJMMF9 dDB2uj8BeoRPSYbpGl7irYUYFpq4TyocQ7qpHdYASC+NV8VTaTrFnHWqa/CGRdp3GHpkgxfOBvpa mOK8udHQYQo2uA3YNd2+j7p4C3jkGG+Z6RrZOskPEwtaIHLxBiA141dhCy5EScOyNajrAXQupsDn vr2ib2ef+4nObPFvedPWIe57lyj0n3e1rTqTGIBIe9wjNnAA6MqeaTS9HchPtBvOrah/cTWzXzGj wMz0P3UJqTQ2r5EAu12/W5kpAgMBAAGjggG4MIIBtDCBigYIKwYBBQUHAQEEfjB8MC0GCCsGAQUF BzABhiFodHRwOi8vb2NzcC50cnVzdC50ZWxpYXNvbmVyYS5jb20wSwYIKwYBBQUHMAKGP2h0dHA6 Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNl cjASBgNVHRMBAf8ECDAGAQH/AgEAMFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQECMDowOAYIKwYB BQUHAgEWLGh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMEsGA1Ud HwREMEIwQKA+oDyGOmh0dHA6Ly9jcmwtMy50cnVzdC50ZWxpYXNvbmVyYS5jb20vdGVsaWFzb25l cmFyb290Y2F2MS5jcmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA4GA1UdDwEB/wQE AwIBBjAdBgNVHQ4EFgQUsQ3K1Ea3r4YCwy9vBsoOdnF/SzcwHwYDVR0jBBgwFoAU8I9ZOACz9Y+a lgzV6/p7qhfoExIwDQYJKoZIhvcNAQEFBQADggIBAG4HIGyvrHc9kEKyYZtxJn9cv7S2dUxuUieg mAvUGHc+JGJyB2jyX7py9an8CsHAxg3BI3Ku9j0h7DJpXyfrlzmg36XYkNS7Ot0A1UqdjGFrtnII SI+Zj3ywHZudmDF8ktdBihHAjuk47B/Kg/Z8JhUJ37GGx/KxiIiXg5HMTdOl6mlDbJaTIEGagdRc mH3u57r5snZ+qdVSg5UxWdhgS2+zPru/vDbPd+91zLTj9GejKXFJ6fEAOLW1j2IjJ0cyDI67d1/O zFTwCK8wYbhopK2wJ9QTKDQuWRuGoyt2d6yzd7WoAS55JE0BIt+kXDJGbOaK42H2ifO6ERHbJiEr /oh4KzgdAes+GRjwlSaG2Z0va4Ss5lY6zfwVCEZYdZcjSDpKB0M5tTQYQeO7QyQPOI6Gb4FXA9ko 3sHvAPs4+Pq+UtWjp3y8sYr1vLCER9ePEsgLdCG27mUk9OAijkG6n5oEGOIn+70F+qvKpmm52dZ8 b7DELfbuuk0CrY4p0WxH3bBt6FJkPeZJIB6YNXAYHZi7RcdBjLJh+lawbIYTJFIcoWFHAl0g0/NY sjz3DLhZz4+CrJ6SQSYmp7qDhdJAWPiaq3C+qE/h2DZAJwoz9uHrZHB8zsZ5JL8sUZ7zgqYmNMN+ 9PxzasrycTJn96Y63AIZdDq1kIHIw0vF4PBTVMZtMYICljCCApICAQEwTjA6MREwDwYDVQQKDAhF cmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MgIQMQ1yPcGTNYDz hYWhrkFQyDAJBgUrDgMCGgUAoIIBHTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3 DQEJBTEPFw0xNzA2MjkwNTE3NDRaMCMGCSqGSIb3DQEJBDEWBBRYN+5cSgQtqd8PMymPkGukKujd cDBdBgkrBgEEAYI3EAQxUDBOMDoxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3Nv biBOTCBJbmRpdmlkdWFsIENBIHYyAhAxDXI9wZM1gPOFhaGuQVDIMF8GCyqGSIb3DQEJEAILMVCg TjA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBD QSB2MgIQMQ1yPcGTNYDzhYWhrkFQyDANBgkqhkiG9w0BAQEFAASCAQBloLk6UVnm7gwIboVTDIUl xyw12xWdfo/MZzdDC5BOqA8B/K4CBcYFdA6AjciVYDUuaiC+3BEZotAh5rmNmc8earU7Z8sNYV4H AThNO6wYpN1dKVH/NnwioTwcE3n782brqbcea9ox0voBcfv3V7Ac45fen47ft/LRtbRxyLtwmrfa beT0hutFS5rmluurxuJEjEDtX0GMOW42g5WzoSJdPntTNf7DiC3+P4yBAVWBGHiENpKVgGVcJmeZ DFM7N4Rm5ILJe5h8Mjn9qpiYQ5f/fHGMlYT1IVbP1e8BZZI1JMlnT+GnezBYPLmhrNrf6P94tMWt hpYzqnl/wHCXHvVFAAAAAAAA --Apple-Mail-DCB780C2-2F26-48E1-B072-0FE5299937B8-- From nobody Thu Jun 29 03:59:58 2017 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6FB012EC03 for ; Thu, 29 Jun 2017 03:59:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 KOIqpRex3eLH for ; Thu, 29 Jun 2017 03:59:53 -0700 (PDT) Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34B14127876 for ; Thu, 29 Jun 2017 03:59:53 -0700 (PDT) Received: by mail-qk0-x233.google.com with SMTP id p21so72775053qke.3 for ; Thu, 29 Jun 2017 03:59:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=yjKZ6pdf0nNYY0Q8EgQ1eQxRRwvLBGPAebNHQjx1dso=; b=NcA5z7Pn3np2iO5ElI9O7c2xdDfcg7h+XtIU99lIIgciQF02D5jZ+bkLGr9zZCSyOp WRiySoMpGdfvz11SfiSof6b4jYzFOheW0ZgHey2MFHRQHH+ou1y9uxqjOk+kJqWzcTKd c24MM0xEuAewbUeaSF4ZepVO7b7RLG0obU/mH+8ix6JWOCjg0gCBiX/kBWP5E6JKI6x7 LwHz4BB2gWoXkH0U7tVj2lpYU8tqtsIu/IzCF0b6XSM4Hwj+5HrxYjOUMhDL9N1qh70J l8vX/hPYDAowdhD3qvtU5g8OtL5lk0LWJKYGi5t1DoPCpwttCxCHrmlYrmEkGA1ObcHp 3qeQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=yjKZ6pdf0nNYY0Q8EgQ1eQxRRwvLBGPAebNHQjx1dso=; b=kp5cr7+GTiKFwKaExn4ejcPjpRbW+DQQlvCyw1bmSacjwHlchWgYV6qrLhjSNb7pmA uSxERHbUMcnF2fwl3qkPhnJZZQL3DjbBUOQMkUpO3tqeqIEsoecLkxBgeizwB9pNnFNJ n3CbsQQG5ZaUZKF0QlZA6pw8p61CzsIylbgGXVPRepQ+VI3oMbaRRv0SF8YWhMbMh+8y 15WHMsk+OR73Gos2ZpMwPOEPu0zdy3yNUbJLrfPSLr0uu2tp6CuA2yn2x2bt5wew+eOe lcZXkWlRR8w64i6pSuL7enQd5NEmCYhL54fe0qibVxyWYzTBXSixr9dPjvhoYeaIakRU RDtw== X-Gm-Message-State: AIVw111PnQU+KRuvpLZGu/LbGkOclQi/BXAE5ATh8Qpbax6vH2ob8lvO frUEg7WMnuHhfeOOaEDQp0RImEebeVlANSLaAQ== X-Received: by 10.55.59.66 with SMTP id i63mr3126962qka.15.1498733992124; Thu, 29 Jun 2017 03:59:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.172.132 with HTTP; Thu, 29 Jun 2017 03:59:51 -0700 (PDT) In-Reply-To: <1ECCF540-3D1F-4032-A783-381E2B16D929@ericsson.com> References: <149857920657.31053.9792912095929561449@ietfa.amsl.com> <6c6dbeae-e204-5a58-a8a8-14be746fb40a@stpeter.im> <9ecc8e18-79d6-6d4b-ac90-3f87f939cdb8@stpeter.im> <1ECCF540-3D1F-4032-A783-381E2B16D929@ericsson.com> From: Taylor Brandstetter Date: Thu, 29 Jun 2017 03:59:51 -0700 Message-ID: To: Christer Holmberg Cc: Peter Saint-Andre , "ice@ietf.org" Content-Type: multipart/alternative; boundary="001a1148bc74376d8405531733d8" Archived-At: Subject: Re: [Ice] I-D Action: draft-ietf-ice-trickle-12.txt X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jun 2017 10:59:56 -0000 --001a1148bc74376d8405531733d8 Content-Type: text/plain; charset="UTF-8" > > Note that 2) only happens if there is no pair(s) for the same foundation > in Waiting/In-Progress state. That's the "whole column is also frozen" part. But you only enter that step in the first place if there are Frozen pairs in the checklist and no Waiting pairs, which is the "whole row is frozen" part. I think we're on the same page, I was just oversimplifying things a bit. On Wed, Jun 28, 2017 at 10:17 PM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > In general, when the spec says "ICE specifies", it would be good with a > reference to the section in 5245bis. > > Regards, > > Christer > > Sent from my iPhone > > > On 29 Jun 2017, at 1.00, Peter Saint-Andre wrote: > > > >> On 6/28/17 1:57 AM, Taylor Brandstetter wrote: > >> Then, as the checks proceed (see Section 6.2.5.4 of [rfc5245bis > >> rfc5245bis>]), > >> for each pair that enters the Succeeded state (denoted here by > "S"), > >> the agent will unfreeze all pairs for all media streams with the > same > >> foundation (e.g., if the pair in column 1, row 1 succeeds then the > >> agent will unfreeze the pair in column 1, row 2). > >> > >> > >> Sorry to keep nitpicking about this section... But since this changed > >> from "the same media stream" to "all media streams", "pair in column 1, > >> row 2" should be replaced with "pairs in column 1, rows 2, 3 and 4". > > > > Good catch, will fix. > > > >> ICE also specifies > >> that, if all the pairs in a media stream for one foundation are > >> unfrozen (e.g., column 1, rows 1 and 2 representing both > components > >> for the audio stream), then all of the candidate pairs in the > entire > >> column are unfrozen (e.g., column 1, rows 3 and 4). > >> > >> > >> This isn't true any more. RFC5245bis appears to only have two rules > >> about unfreezing now: > >> > >> 1. If a pair succeeds, everything with the same foundation is unfrozen. > >> 2. If Ta fires for a checklist, and its whole row is frozen, every cell > >> that's part of a column that's completely frozen is unfrozen > >> (enforced by section 5.1.4.2, step 2). This is still pretty weird, > >> but at least not as complex as the "for each component" rule before. > >> > >> #2 isn't called out. Should it be? > > > > I'll let you and Christer decide on what's right here. ;-) > > > > Peter > > > > > > _______________________________________________ > > Ice mailing list > > Ice@ietf.org > > https://www.ietf.org/mailman/listinfo/ice > --001a1148bc74376d8405531733d8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Note that 2) only happens if there is no pair(s) f= or the same foundation in Waiting/In-Progress state.

That's the "whole column is also frozen" par= t. But you only enter that step in the first place if there are Frozen pair= s in the checklist and no Waiting pairs, which is the "whole row is fr= ozen" part. I think we're on the same page, I was just oversimplif= ying things a bit.

On Wed, Jun 28, 2017 at 10:17 PM, Christer Holmberg <christer.holmberg@ericsson.com> wrote:
Hi,

In general, when the spec says "ICE specifies", it would be good = with a reference to the section in 5245bis.

Regards,

Christer

Sent from my iPhone

> On 29 Jun 2017, at 1.00, Peter Saint-Andre <stpeter@stpeter.im> wrote:
>
>> On 6/28/17 1:57 AM, Taylor Brandstetter wrote:
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0Then, as the checks proceed (see Section= 6.2.5.4 of [rfc5245bis
>>=C2=A0 =C2=A0 <https:= //tools.ietf.org/html/draft-ietf-ice-trickle-12#ref-rfc5245bis>]),
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0for each pair that enters the Succeeded = state (denoted here by "S"),
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0the agent will unfreeze all pairs for al= l media streams with the same
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0foundation (e.g., if the pair in column = 1, row 1 succeeds then the
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0agent will unfreeze the pair in column 1= , row 2).
>>
>>
>> Sorry to keep nitpicking about this section... But since this chan= ged
>> from "the same media stream" to "all media streams&= quot;, "pair in column 1,
>> row 2" should be replaced with "pairs in column 1, rows = 2, 3 and 4".
>
> Good catch, will fix.
>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0ICE also specifies
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0that, if all the pairs in a media stream= for one foundation are
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0unfrozen (e.g., column 1, rows 1 and 2 r= epresenting both components
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0for the audio stream), then all of the c= andidate pairs in the entire
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0column are unfrozen (e.g., column 1, row= s 3 and 4).
>>
>>
>> This isn't true any more. RFC5245bis appears to only have two = rules
>> about unfreezing now:
>>
>> 1. If a pair succeeds, everything with the same foundation is unfr= ozen.
>> 2. If Ta fires for a checklist, and its whole row is frozen, every= cell
>>=C2=A0 =C2=A0 that's part of a column that's completely fro= zen is unfrozen
>>=C2=A0 =C2=A0 (enforced by section 5.1.4.2, step 2). This is still = pretty weird,
>>=C2=A0 =C2=A0 but at least not as complex as the "for each com= ponent" rule before.
>>
>> #2 isn't called out. Should it be?
>
> I'll let you and Christer decide on what's right here. ;-)
>
> Peter
>
>
> __________________= _____________________________
> Ice mailing list
> Ice@ietf.org
> https://www.ietf.org/mailman/listinfo/ice

--001a1148bc74376d8405531733d8--