Subject: Re: [Ice] Trickle: A couple of questions on section 7

From: Nils Ohlmeier <[email-masked]>
Date: Fri, 2 Mar 2018 10:20:26 -0800

> On Feb 27, 2018, at 11:29, Christer Holmberg <[email-masked]> wrote:
>> 
>>>>> *Q1:*
>>>>> 
>>>>> Section 7.1 says:
>>>>> 
>>>>>   "The ICE specification [rfc5245bis], Section 6.1.4.2, specifies
>>>>>    that an agent will terminate the timer for a triggered check in
>>>>>    relation to a check list once the agent has exhausted all frozen pairs in
>>>>>    the check list.  This will not work with Trickle ICE, because more
>>>>>    pairs will be added to the check list incrementally."
>>>>> 
>>>>> Exactly what procedure in 5245bis dos this text refer to?
>>>> 
>>>> Hmm, good question. Emil wrote that text so we might want to check
>>>> with him, but looking at 5245bis I'd say it refers to the last
>>>> sentence in Step 4 of §6.1.4.2:
>>>> 
>>>>  4.  If this step is reached, no check could be performed for the
>>>>      picked check list.  So, without waiting for timer Ta to expire
>>>>      again, select the next check list in the Running state and return
>>>>      to step #1.  If this happens for every single check list in the
>>>>      Running state, meaning there are no remaining candidate pairs to
>>>>      perform connectivity checks for, abort these steps.
>>>> 
>>>> However, that refers to exhausting all the candidate pairs to be
>>>> checked for all check lists, not to "terminat[ing] the timer for a
>>>> triggered check in relation to a check list once the agent has
>>>> exhausted all frozen pairs in the check list". So we might want to ping Emil.
>>> 
>>> I think "terminate the timer" is misleading wording. Timer Ta is not
>>> terminated as long as there is at least one check list in "Running" mode.
>>> 
>>> It is true that, whenever timer Ta fires, check lists that are not in
>>> the "Running" mode will not be checked. But, even with legacy ICE, a
>>> check list may put back in "Running" mode if e.g., a triggered check
>>> changes that status of a failed pair, and if that pair state change
>>> affects the state of the check list.
>>> 
>>> So, unless I¹ve missed something, I don¹t think that trickle changes
>>> how check lists are checked when Ta fires. If additional candidates
>>> have been gathered, and added to a check list, step 4) in section
>>> 6.1.4.2 will not be reached.
>> 
>> I suspect that Emil might have been thinking about trickling of candidates after nomination of a
>> candidate pair, but we'll drag him into the conversation one way or another. ;-)
> 
> I think you raise an important point. Once you have nominated a pair, you can't nominate another pair (that would be "continuous nomination", which is outside the scope of trickle). I think you should add text about that, because I don't think it is currently mentioned. The draft does say that "ICE processing" might end before end-of-candidates have been conveyed, but that's a separate thing. I guess nomination would also implicitly mean end-of-candidates, and neither agent should trickle any more candidates after nomination is done.

Stopping to trickle is one aspect of it. But there can also be still trickled candidates in flight over the signaling path which arrive after nomination has concluded on the ICE layer. I think it makes more sense to address this on the receiving end and advise that ICE agents which still receive candidates after nomination has concluded, should ignore these new candidates.

Another aspect might be continuous nomination in the future. If we demand that the emitting agents stops trickling it might be harder to open it up for continuous nomination again. Where if we only tell the receiving agent to ignore candidates which arrive after nomination has concluded it should be trivial for continuous nomination to lift/change that part of the spec.

Best regards
  Nils Ohlmeier

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 2 Mar 2018 14:21:31 -0700

> Stopping to trickle is one aspect of it. But there can also be still trickled candidates in flight over the signaling path which arrive after nomination has concluded on the ICE layer. I think it m…

Yes, that seems reasonable. A good location for this text is Section 10:

OLD
   When an agent receives an end-of-candidates indication for a specific
   media stream, it will update the state of the relevant check list as
   per Section 7.2.  If the check list is still in the Active state
   after the update, the agent will persist the fact that an end-of-
   candidates indication has been received and take it into account in
   future updates to the check list.

NEW
   When an agent receives an end-of-candidates indication for a specific
   media stream, it will update the state of the relevant check list as
   per Section 7.2.  If the check list is still in the Active state
   after the update, the agent will persist the fact that an end-of-
   candidates indication has been received and take it into account in
   future updates to the check list. Although the agent might receive
   additional "inf-flight" candidates after receiving the end-of-
   candidates indication, it MUST ignore those candidates.

> Another aspect might be continuous nomination in the future. If we demand that the emitting agents stops trickling it might be harder to open it up for continuous nomination again. Where if we only…

Good point.

Peter

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 2 Mar 2018 21:42:18 +0000

Hi,

>>>>> I think "terminate the timer" is misleading wording. Timer Ta is 
>>>>> not terminated as long as there is at least one check list in "Running" mode.
>>>>>
>>>>> It is true that, whenever timer Ta fires, check lists that are not 
>>>>> in the "Running" mode will not be checked. But, even with legacy 
>>>>> ICE, a check list may put back in "Running" mode if e.g., a 
>>>>> triggered check changes that status of a failed pair, and if that 
>>>>> pair state change affects the state of the check list.
>>>>>
>>>>> So, unless I¹ve missed something, I don¹t think that trickle 
>>>>> changes how check lists are checked when Ta fires. If additional 
>>>>> candidates have been gathered, and added to a check list, step 4) 
>>>>> in section
>>>> I suspect that Emil might have been thinking about trickling of 
>>>> candidates after nomination of a candidate pair, but we'll drag him 
>>>> into the conversation one way or another. ;-)
>>>
>>> I think you raise an important point. Once you have nominated a pair, you can't nominate another 
>>> pair (that would be "continuous nomination", which is outside the scope of trickle). I think you 
>>> should add text about that, because I don't think it is currently mentioned. The draft does say that 
>>> "ICE processing" might end before end-of-candidates have been conveyed, but that's a separate thing. 
>>> I guess nomination would also implicitly mean end-of-candidates, and neither agent should trickle any 
>>> more candidates after nomination is done.
>> 
>> Stopping to trickle is one aspect of it. But there can also be still trickled candidates in flight over the signaling path 
>> which arrive after nomination has concluded on the ICE layer. I think it makes more sense to address this on the 
>> receiving end and advise that ICE agents which still receive candidates after nomination has concluded, should 
>> ignore these new candidates.
>

First, "Active state" (actually, it was never even a state, just a "property") has been removed from 5245bis, so we should not use that terminology. I guess it should be "Running state".

Second, what does the "If the check list..." sentence actually mean? What will be taken into account?

Third, if the agent receives additional candidates, should it accept or reject the message carrying them? The exact way of accepting and rejecting is of course protocol specific, but I think the draft should give some guidance. In my opinion the messages should be rejected, to inform the peer that the agent is not going to do anything with the candidates.

> Another aspect might be continuous nomination in the future. If we demand that the emitting agents stops trickling it might be harder 
> to open it up for continuous nomination again. Where if we only tell the receiving agent to ignore candidates which arrive after nomination 
> has concluded it should be trivial for continuous nomination to lift/change that part of the spec.

IF we decide to do continuous nomination, we can always change the rules for that.

Regards,

Christer

---

From: Emil Ivov <[email-masked]>
Date: Mon, 5 Mar 2018 21:36:51 -0600

Hey Christer,

Inline:

On Sun, Feb 25, 2018 at 1:41 PM, Christer Holmberg
<[email-masked]> wrote:
> Hi,
>
> While catching some breath between trying to address IESG comments on
> 5245bis, I took a look at trickle-16, and I have a couple of questions.
>
> Q1:
>
> Section 7.1 says:
>
>    “The ICE specification [rfc5245bis], Section 6.1.4.2, specifies that
>    an agent will terminate the timer for a triggered check in relation
>    to a check list once the agent has exhausted all frozen pairs in the
>    check list.  This will not work with Trickle ICE, because more pairs
>    will be added to the check list incrementally.”
>

At the time of writing that was section 5.8 in 5245 and specifically this text:

 *  If there is no such pair:
         +  Terminate the timer for that check list.

I am not able to match that to text in 5245 bis and it probably went
away last year when we were redoing the states. We'd need to resync
it. Want to have a quick call offlist? (I suspect we can probably just
drop this after the latest changes we did in Prague last year).

> Q2:
>
> Section 7.2 says:
>
>    “When a check list is set to Failed as described above, regular ICE
>    requires the agent to update all other check lists, placing one pair
>    from each check list into the Waiting state and thereby effectively
>    placing all remaining check lists into the Running state.”
>

Exactly the parts that we discussed and agreed to change in Prague
last year. I think this part is no longer necessary given how they are
covered by 5245bis.

Emil

-- 
https://jitsi.org

---

From: Nils Ohlmeier <[email-masked]>
Date: Mon, 5 Mar 2018 20:39:51 -0800

> On Mar 2, 2018, at 13:42, Christer Holmberg <[email-masked]> wrote:
> 

Fair enough.

The other worry I have with restricting on the emitting side is that effectively ICE and the signaling layer are in a race, which most scenarios the signaling layer is going to loose. That results in ICE agent receiving trickle candidates very likely getting into the scenario where ICE has concluded with use-candidate being set, but still receiving candidates via the signaling layer. If you want to suggest what to do with these late arrivals, e.g. rejecting, then we need some text explaining this scenario any way.

So for me it’s:
- either only describe the receiving ICE agent ignores late arriving candidates
- or demanding that the emitting ICE candidate shall stop emitting AND the receiving ICE agent also needs to ignore late arrival to be safe

Best
  Nils Ohlmeier

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 6 Mar 2018 07:47:35 +0000

Hi,

>>>Another aspect might be continuous nomination in the future. If we
>>>demand that the emitting agents stops trickling it might be harder
>>> to open it up for continuous nomination again. Where if we only tell
>>>the receiving agent to ignore candidates which arrive after nomination
>The other worry I have with restricting on the emitting side is that
>effectively ICE and the signaling layer are in a race, which most
>scenarios the signaling layer is going to loose. That results in ICE
>agent receiving trickle candidates very likely getting into the scenario
>where ICE has concluded with use-candidate being set, but still receiving
>candidates via the signaling layer. If you want to suggest what to do
>with these late arrivals, e.g. rejecting, then we need some text
>explaining this scenario any way.
>
>So for me it¹s:
>- or demanding that the emitting ICE candidate shall stop emitting AND
>the receiving ICE agent also needs to ignore late arrival to be safe

Not sure what you mean by ³ignore², but I think the message carrying the
trickled candidates should be explicitly rejected, so that the emitting
agent knows what is going on.

Then, in future, if continuous nomination is supported, instead of
rejecting the message carrying the candidates it is simply accepted :)

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 6 Mar 2018 08:00:19 +0000

Hi Emil,

We can for sure have a call, but I think this requires a bigger audience
than you and me :)

I assume that the authors should participate, and also individuals like
Nils O, Taylor B, Peter S-A etc.

As far as I understand, trickle has 3 major considerations compared to
legacy ICE:

1) The order in which candidates are trickled. As we have discussed
lately, it needs to be clarified.
2) How trickle impacts the check list state. In fact, I am not sure it
impacts at all, because 5245bis nowadays says that a Failed checklist can
become Running again if the state of a pair within the check list changes
(with legacy ICE this can happen by the triggered check).
3) Once the nomination has taken place, we need to describe what happens
with trickled candidates that may still arrive.

That would be 3 sections in the trickle spec :)

Are you going to be in London, btw?

Regards,

Christer

On 06/03/18 05:36, "Emil Ivov" <[email-masked]> wrote:

>>    ³The ICE specification [rfc5245bis], Section 6.1.4.2, specifies that
>>    will be added to the check list incrementally.²
>>
>>    ³When a check list is set to Failed as described above, regular ICE
>>    placing all remaining check lists into the Running state.²
>>

---

From: Emil Ivov <[email-masked]>
Date: Tue, 06 Mar 2018 12:23:47 +0000

Hey Christer,

> Nils O, Taylor B, Peter S-A etc.

As much as I’d be trilled to have any number of chats in such lovely
company, I just wanted your help on finding the right sections in bis so
that we would simply update the coherence of the document.

Let’s see then if further discussion is necessary after that.

> Are you going to be in London, btw?

Nope. Justhad a humans++ event at home so IETF (even in London) loses the
prioritization contest there ;)

I’d likely be able to do remot though.

Emil

> >last year. I think this part is no longer necessary given how they are
—sent from my mobile

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 6 Mar 2018 13:06:22 +0000

Hi,

Congratulations to the added human!:)

>company, I just wanted
>your help on finding the right sections in bis so that we would simply
>update the coherence of the document.
>

Based on your input in the previous reply, I think I understand where Q1
comes from. I still have an issue with Q2, though. See below.

>drop this after the latest changes we did in Prague last year).

Ok, I think I get it now.

In RFC 5245 (and earlier versions of 5245bis) we had a *separate* timer Ta
for each check list. So, once there were no more checks to be done for a
check list, the timer for a given check list was terminated.

In 5245bis, however, we only use a *single* timer Ta for the whole check
list set, and whenever Ta fires we check the next Running check list in
the check list set. So, non-Running check lists will automatically be
skipped. This is described in section 6.1.4.2.

So, I am not sure whether you need to say anything in trickle, because
whether a check list is checked or not is taken care of by the 5245bis
procedures.

>last year. I think this part is no longer necessary given how they are

But, are you saying that the text above is according to 5245bis?

Regards,

Christer

---

From: Nils Ohlmeier <[email-masked]>
Date: Tue, 6 Mar 2018 09:49:31 -0800

> On Mar 5, 2018, at 23:47, Christer Holmberg <[email-masked]> wrote:
> 
>> Fair enough.
>> 

With “ignore” I mean that the ICE agent should not add these late arrivals to any check lists.
If the agent would add the late candidate to check lists you effectively would have implemented continuous nomination.

Wether you then return on the API side of the ICE agent “Ok” or “Reject” I think is a separate discussion.
And I would tend to argue that the IETF usually does not design APIs.

> rejecting the message carrying the candidates it is simply accepted :)

That was the previous point I was trying to make :-)

Cheers
  Nils

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 6 Mar 2018 19:33:15 +0000

Hi,

>>> agent receiving trickle candidates very likely getting into the 
>>> scenario where ICE has concluded with use-candidate being set, but 
>>> still receiving candidates via the signaling layer. If you want to 
>>> suggest what to do with these late arrivals, e.g. rejecting, then we 
>>> need some text explaining this scenario any way.
>>> 
>>> So for me it¹s:
>>> - or demanding that the emitting ICE candidate shall stop emitting 
>>> AND the receiving ICE agent also needs to ignore late arrival to be 
>>> safe
>> 
>> Not sure what you mean by ³ignore², but I think the message carrying 
>> the trickled candidates should be explicitly rejected, so that the 
>> emitting agent knows what is going on.
>

Yes.

> And I would tend to argue that the IETF usually does not design APIs.

True. But, IETF does design protocols, and I was talking about informing the peer that the candidates he trickled to me where rejected :)

Exactly how it is done is of course depending on the ICE usage protocol, but the ICE WG spec should define the high-level procedure.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 14 Mar 2018 08:55:54 +0000

Hi,

Is someone planning to do something (update the draft) related to this?

Regards,

Christer

On 06/03/18 21:33, "Ice on behalf of Christer Holmberg"
<[email-masked] on behalf of [email-masked]> wrote:

>> If the agent would add the late candidate to check lists you
>>effectively would have implemented continuous nomination.
>
>Yes.
>
>> Wether you then return on the API side of the ICE agent “Ok” or
>>“Reject” I think is a separate discussion.
>True. But, IETF does design protocols, and I was talking about informing
>the peer that the candidates he trickled to me where rejected :)
>
>Exactly how it is done is of course depending on the ICE usage protocol,
>but the ICE WG spec should define the high-level procedure.
>
>Regards,
>
>Christer
>_______________________________________________
>Ice mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/ice

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 14 Mar 2018 08:57:37 +0000

Note that the draft is on the IESG telechat agenda in the beginning of
April. I think the issues we have agreed exist should be fixed before that.

Regards,

Christer

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 14 Mar 2018 02:05:35 -0700

They certainly will be fixed by then. Emil and I will coordinate.

Sent from mobile, might be terse 

> On Mar 14, 2018, at 1:57 AM, Christer Holmberg <[email-masked]> wrote:
>

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 20 Mar 2018 14:48:58 -0600

> Congratulations to the added human!:)

+1!

> whether a check list is checked or not is taken care of by the 5245bis

That seems reasonable and I can adjust the text accordingly.

> But, are you saying that the text above is according to 5245bis?

I can't speak for Emil, but IMHO it's best to remove that text so the
question is moot.

Peter

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 20 Mar 2018 21:00:26 -0600

> That seems reasonable and I can adjust the text accordingly.

By which I mean: remove Section 7.1 entirely.

> I can't speak for Emil, but IMHO it's best to remove that text so the

Looking at this further, I realize that I have a question about 5245bis:
according to ICE Core, is it possible to have an empty check list? By my
reading of Section 6.1.2, a check list must have candidate pairs in it.
However, in Trickle ICE we can have empty check lists. That's at least
in part what Section 7.2 of the trickle spec is about.

Peter

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 24 Mar 2018 16:19:20 +0000

Hi,

>>>> At the time of writing that was section 5.8 in 5245 and specifically 
>>>> this
>>>> text:
>>>>
>>>> it. Want to have a quick call offlist? (I suspect we can probably 
>>>> just drop this after the latest changes we did in Prague last year).
>>>
>>> In RFC 5245 (and earlier versions of 5245bis) we had a *separate* 
>>> timer Ta for each check list. So, once there were no more checks to 
>>> be done for a check list, the timer for a given check list was terminated.
>>>
>>> In 5245bis, however, we only use a *single* timer Ta for the whole 
>>> check list set, and whenever Ta fires we check the next Running check 
>>> list in the check list set. So, non-Running check lists will 
>>> automatically be skipped. This is described in section 6.1.4.2.
>>>
>>> So, I am not sure whether you need to say anything in trickle, 
>>> because whether a check list is checked or not is taken care of by 
>>> the 5245bis procedures.
>> 

I am not sure it shall be removed, because I think there IS something to say. But, the text needs to be adjusted, e.g., as following:

"7.1.  Check List State

   [rfc5245bis] specifies that, whenever timer Ta fires, only check lists
   in Running state will be picked in order to check for candidate pairs
   for which connectivity checks are scheduled.

   Therefore, an Trickle ICE agent MUST keep each check list in Running
   state as long as new pairs are incrementally added to the check list.
   After that, the check list state is set according to the procedures in
   [rfc5245bis]."

---

>>>> last year. I think this part is no longer necessary given how they 
>>>> are covered by 5245bis.
>>>
> according to ICE Core, is it possible to have an empty check list? 
> By my reading of Section 6.1.2, a check list must have candidate pairs in it.
> However, in Trickle ICE we can have empty check lists. That's at least in part what 
> Section 7.2 of the trickle spec is about.

I am not sure what an empty check list is. 

Shouldn't the text be talking about adding new check lists to the check list set instead?

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 24 Mar 2018 16:28:02 +0000

Hi,

...

> I am not sure what an empty check list is. 

I withdraw that statement. I was thinking about something else.

Now, 5245bis obviously assume that there are candidate pairs in each check list from the beginning.

So, if the only think you want to say is that a check list might initially be empty, I think the section name should be "Empty Check Lists", and then you only need a couple of sentences to point it out.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 24 Mar 2018 17:37:47 +0000

Hi,

Below is some comments on the current text in section 7.2:

(In general, please replace "The ICE specification" with "[rfc5245bis]".) 

---

+7.2.  Check List and Timer State Updates
+
+   The ICE specification [rfc5245bis], Section 7.2.5.3.3, requires that
+   agents update check lists and timer states upon completing a
+   connectivity check transaction.  During such an update, regular ICE
+   agents would set the state of a check list to Failed if both of the
+   following two conditions are satisfied:
+
+   o  all of the pairs in the check list are either in the Failed state
+      or Succeeded state; and
+
+   o  there is not a pair in the valid list for each component of the
+      media stream.
+
+   With Trickle ICE, the above situation would often occur when
+   candidate gathering and trickling are still in progress, even though
+   it is quite possible that future checks will succeed.  For this
+   reason, Trickle ICE agents add the following conditions to the above
+   list:
+
+   o  all candidate gathering has completed and the agent is not
+      expecting to discover any new local candidates;
+
+   o  the remote agent has conveyed an end-of-candidates indication for
+      that check list as described in Section 8.2.

[Christer] I think more or less everything above is covered by the new text I suggested for section 7.1. In short: keep the check list in Running state until there are no more trickled pairs.

+   When a check list is set to Failed as described above, regular ICE
+   requires the agent to update all other check lists, placing one pair
+   from each check list into the Waiting state 

[Christer] I don't think this is true. Is there text in 5245bis defining this?

+   and thereby effectively placing all remaining check lists into the Running state.  

[Christer] This sounds weird. In 5245bis all check lists states are set to Running by default.

+   However,
+   under Trickle ICE other check lists might still be empty at this
+   point (because candidates have not yet been received), and following
+   only the rules from regular ICE would prevent the agent from forming
+   those check lists (because the state of a check list depends on the
+   state of the candidate pairs in that check list, but there might not
+   yet by any candidate pairs in a given check list).  In accordance
+   with the ICE specification [rfc5245bis], Section 6.1.2.1, a Trickle
+   ICE agent considers an empty check list to be in the Running state;

[Christer] This can be simplified: simply indicate that some check lists may initially be empty, but are still initially set in Running state according to the procedures in 5245bis. In addition you can say that, whenever Ta fires and an empty check list is picked, no actions are performed for that check list.

+   in accordance with Section 8.1.1, when inserting a new candidate pair
+   into an empty check list, the agent sets the pair to a state of
+   Waiting.

[Christer] This is not needed here. Section 8.1.1 defines the state of new candidate pairs, no matter if they are inserted into an empty or non-empty check list.

So, based on my analysis, the only thing you need to keep is the empty check list part.

Regards,

Christer

-----Original Message-----
From: Christer Holmberg 
Sent: 24 March 2018 18:28
To: Christer Holmberg <[email-masked]>; Peter Saint-Andre <[email-masked]>; Emil Ivov <[email-masked]>
Cc: [email-masked]
Subject: RE: [Ice] Trickle: A couple of questions on section 7

Hi,

...

>>> I can't speak for Emil, but IMHO it's best to remove that text so 
>>> the question is moot.
>>
>> However, in Trickle ICE we can have empty check lists. That's at 
>> least in part what Section 7.2 of the trickle spec is about.
>

Regards,

Christer

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 27 Mar 2018 09:52:02 -0600

Yes.

> So, if the only think you want to say is that a check list might initially be empty, I think the section name should be "Empty Check Lists", and then you only need a couple of sentences to point it…

I suggest:

   A Trickle ICE agent will create a check list even if it does
   not yet have any candidates to put in that check list (this scenario
   does not arise with non-trickle agents, because all candidates are
   known when the agent creates the check list set); in accordance with
   the ICE specification [rfc5245bis], Section 6.1.2.1, a Trickle ICE
   agent considers an empty check list to be in the Running state.

Peter

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 27 Mar 2018 09:54:17 -0600

>    After that, the check list state is set according to the procedures in

Yes, that is a more accurate description of trickle ICE agent behavior.
Thanks for the text!

Peter

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 27 Mar 2018 10:34:29 -0600

> (In general, please replace "The ICE specification" with "[rfc5245bis]".) 

Although opinions vary on this stylistic question, over the years I've
come to see the wisdom of using xref only for the actual citation and
not in running prose. Thus I'd prefer not to make this change.

> [Christer] I think more or less everything above is covered by the new text I suggested for section 7.1. In short: keep the check list in Running state until there are no more trickled pairs.

Agreed.

> [Christer] This sounds weird. In 5245bis all check lists states are set to Running by default.

Here again, I don't think we need to summarize what 5425bis says.

> So, based on my analysis, the only thing you need to keep is the empty check list part.

Agreed.

Peter

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 27 Mar 2018 17:40:00 +0000

Hi,

>>>>>>> Exactly the parts that we discussed and agreed to change in 
>>>>>>> Prague last year. I think this part is no longer necessary given 
>>>>>>> how they are covered by 5245bis.
>>>>>>
>> So, if the only think you want to say is that a check list might initially 
>> be empty, I think the section name should be "Empty Check Lists", and 
>> then you only need a couple of sentences to point it out.
>
> I suggest:
>

A check list does not contain candidates, but candidate pairs. It is also good to mention how an empty list is processed when Ta fires. 

So, a modified suggestion:

     A Trickle ICE agent might create a check list that initially does not contain
     any candidate pairs (they will be incrementally added). This is referred to
     as an empty check list. Similar to other check lists, the state of an empty
     check list is initially set to Running, in accordance with the ICE specification
     [rfc5245bis], Section 6.1.2.1.

     Whenever timer Ta fires, and an empty check list is picked, no actions is performed
     for the list. Without waiting for timer Ta to expire again, the agent selects the next
     check list in the Running state, in accordance with the ICE specification
     [rfc5245bis], Section 6.1.4.2.

Regards,

Christer

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 27 Mar 2018 12:41:32 -0600

On 3/27/18 11:40 AM, Christer Holmberg wrote:
> A check list does not contain candidates, but candidate pairs. 

Indeed. Sorry about the error.

> It is also good to mention how an empty list is processed when Ta fires. 
> 

WFM.

Peter