Original text:
(ICE), for Network Address Translator (NAT) traversal for UDP-based communication. <del> Typically, when using ICE, endpoints will exchange candidate addresses, form a list of candidate pairs, and then test each candidate pair to see if connectivity can be established.  If the test for a given pair fails, it is marked accordingly, and if all pairs have failed, the overall ICE process is considered to have failed. </del>  During the process of connectivity checks, additional candidates may be created as a result of successful inbound checks from the remote the peer agent if it does not know what to do with them.  For example, candidates may use an address family that the peer agent does not support, (e.g., a host candidate with an IPv6 address in a <del> NAT64 scenario), or may not be usable for some other reason (e.g., a candidate that contains a FQDN that fails to resolve). </del>  In these scenarios, when the candidates are discarded, the checklist at the peer agent will once again be empty, leading to immediate ICE needs to wait enough time to allow peer-reflexive candidates to be discovered.  Accordingly, when a full ICE implementation begins its ICE processing, as described in RFC8445, Section 6.1, it MUST set a <del> timer to ensure ICE will run for a minimum amount of time before determining failure. </del>  Specifically, the ICE agent will start its timer once it believes ICE connectivity checks are starting.  This occurs when the agent has Username Fragment and Password denoted in RFC8445, Section 5.3) and has received some indication that the remote side is ready to start connectivity checks, typically via receipt of the values mentioned <del> above; note that receipt of an ICE candidate is not required. </del>  The RECOMMENDED duration for the timer is equal to the agent's connectivity check transaction timeout, including all there are no such checklists, no action is necessary. One consequence of this behavior is that in cases where ICE should <del> fail, e.g., where both sides provide candidates with unresolvable FQDNs ICE will no longer fail immediately, and only fail when the aforementioned timer expires.  However, because most ICE scenarios </del>  require an extended period of time to determine failure, the fact that some specific scenarios no longer fail fast should have minimal application impact, if any. <del> Note also that the timer is potentially relevant to the ICE </del>  nomination procedure described in RFC8445, Section 8.1.1.  That specification does not define a minimum duration for ICE processing prior to nomination of a candidate pair, but in order to select the allow peer-reflexive candidates to be discovered and checked, as noted above.  Accordingly, the controlling ICE agent SHOULD wait a sufficient amount of time before nominating candidate pairs, and it <del> MAY use the timer described above to do so.  As always, the controlling ICE agent retains full discretion, and MAY decide, based on its own criteria, to nominate pairs prior to the timer elapsing. </del>  5.

Reviewer comments:
You are right, eventhoug 8445 in some places do say "whenever Ta fires". I'll update the PR. I think it is much easier to talk about "timer Tpac" than "the timer that does this and that". For example, during the ICEbis work, we often talked about "timer Ta". It may not sound like a big differnce at this point, when we are still working on the draft, but I think it will make a difference in the future when/if people start referring to the timer.
NAME NAME wdyt?
I don't think we need this, but if we want to name the timer, I would suggest: Call it "Tpac" and not "Timer Tpac" Not change so much of the existing text. Maybe put in the name (for future conversations) and just replace the once place where we say "the aforementioned timer".
I initially did that, but Justin pointed out that, when comparing to Ta, Ta is just the interval used by a timer. I think that, when we talk about about a timer, we should use the name of the timer.
The first mentions of timers in 8445 says "The gathering process is controlled using a timer, Ta. Every time Ta expires" but then later is says "The generation of ordinary and triggered connectivity checks is governed by timer Ta". So it looks like 8445 isn't self consistent. Meanwhile, we call the RTO timer "timer RTO", so we don't need the "Tfoo" model. How about we just call it "timer PAC", or better yet "the PAC timer"?
I left that part out on purpose :) The Terminology section uses "Timer Ta", though. I want to have a timer name. As I indicated to Justin when we discussed this, it will make future discussions much easier, when we refer to the timer. It will also make life easier for implementers. What about using "timer Tpac" in the first occurrence, and then "Tpac"? BTW, if you are concerned about the number of changes in the PR, note that we have already merged a set of PRs, so the new version of the draft will contain changes from the current version no matter what.
I don't see any reason to use the T prefix when always say "timer" along with it. It's redundant. I'd prefer "PAC timer or "timer PAC". But I don't care enough to keep talking about it. I'd rather just pick something and move on.
I have no problem with "timer PAC" if you prefer that. All I want is a timer name that people can be refer to.
I think it's very useful to have a name for the timer and both Tpac and PAC timer work for me.
I will merge the pull request. There will still be time (during WGLC, IESG review) to fine tune the timer name, if there is a need to.
There’s still more to do on the PR, but sounds like we have a path forward.
Ok, so I will not merge yet.
Updated the PR to use 'PAC timer', and only where necessary. I'm happy with this if you are.
Looks good.
I think we should give the timer a name. Other ICE timers have names, and it also makes it easier to refer to it in future discussions, drafts, and implementations. I previously suggested Tpac. Tupac would also be cool :)
I created a pull request for this,
Note that 'Ta' in 8445 is the interval, not the timer. It uses 'timer Ta' to refer to the actual timer. I'm not sure this change is an improvement, but open to considering it.LGTM

Revised text:
(ICE), for Network Address Translator (NAT) traversal for UDP-based communication.  <ins> When using ICE, endpoints will typically exchange ICE candidates, form a list of candidate pairs, and then test each candidate pair to see if connectivity can be established.  If the test for a given pair fails, it is marked accordingly, and if all pairs have failed, the overall ICE process typically is considered to have failed. </ins> During the process of connectivity checks, additional candidates may be created as a result of successful inbound checks from the remote the peer agent if it does not know what to do with them.  For example, candidates may use an address family that the peer agent does not support, (e.g., a host candidate with an IPv6 address in a  <ins> NAT64 scenario), or may not be usable for some other reason. </ins> In these scenarios, when the candidates are discarded, the checklist at the peer agent will once again be empty, leading to immediate ICE needs to wait enough time to allow peer-reflexive candidates to be discovered.  Accordingly, when a full ICE implementation begins its ICE processing, as described in RFC8445, Section 6.1, it MUST set a  <ins> timer, henceforth known as the PAC timer, to ensure ICE will run for a minimum amount of time before determining failure. </ins> Specifically, the ICE agent will start its timer once it believes ICE connectivity checks are starting.  This occurs when the agent has Username Fragment and Password denoted in RFC8445, Section 5.3) and has received some indication that the remote side is ready to start connectivity checks, typically via receipt of the values mentioned  <ins> above.  Note that the agent will start the timer even if it has not sent or received any ICE candidates. </ins> The RECOMMENDED duration for the timer is equal to the agent's connectivity check transaction timeout, including all there are no such checklists, no action is necessary. One consequence of this behavior is that in cases where ICE should  <ins> fail, e.g., where both sides provide candidates with unsupported address families, ICE will no longer fail immediately, and only fail when the PAC timer expires.  However, because most ICE scenarios </ins> require an extended period of time to determine failure, the fact that some specific scenarios no longer fail fast should have minimal application impact, if any.  <ins> Note also that the PAC timer is potentially relevant to the ICE </ins> nomination procedure described in RFC8445, Section 8.1.1.  That specification does not define a minimum duration for ICE processing prior to nomination of a candidate pair, but in order to select the allow peer-reflexive candidates to be discovered and checked, as noted above.  Accordingly, the controlling ICE agent SHOULD wait a sufficient amount of time before nominating candidate pairs, and it  <ins> MAY use the PAC timer to do so.  As always, the controlling ICE agent retains full discretion, and MAY decide, based on its own criteria, to nominate pairs prior to the timer elapsing. </ins> 5.