Change:
NAME please review
From Magnus Westerlund in Last Call: . Section 3.3: When a client gathers all IPv6 addresses on a host, and both temporary addresses and permanent addresses of the same scope are present, the client SHOULD discard the permanent addresses before exposing addresses to the application or using them in ICE. This is consistent with the default policy described in [RFC6724]. If some of the temporary IPv6 addresses, but not all, are marked deprecated, the client SHOULD discard the deprecated addresses. I haven't noticed this before, but if you have both permanent and temporary addresses, can all the temporary be marked deprecated? If that can occur, does this specification need to say something in this case which should be used, a deprecated temporary or a permanent one?
Adding "non-deprecated" in front of "temporary" - that seems reasonable. NAME OK with you?
From Spencer Dawkins in IESG review:
From Suresh Krishnan in IESG review: In Section 3.3. Usage of temporary IPv6 addresses, the draft states " The IPv6 default address selection specification [RFC6724] specifies that temporary addresses [RFC4941] are to be preferred over permanent addresses." While this is technically true, this is only the seventh rule in an ordered list of eight rules. e.g. A valid permanent address would be preferred over a deprecated temporary address based on Rule 3. If a host had only a valid permanent address and a deprecated temporary address, the mechanism specified in the draft would result in no addresses being made available, whereas the permanent address would have been an acceptable choice using RFC6724. So, it is not entirely clear to me what the draft is trying to accomplish. It says " However, this rule is not completely obvious in the ICE scope. This is therefore clarified as follows:" What rule is this talking about when it says "this rule"? Similarly, it also says "When a client gathers all IPv6 addresses on a host..." but it is not clear what "client" the draft is referring to. I think if you can clarify what you want to achieve with the address selection we can work together on some replacement text.

Discussion:
addresses.  This is a change from the rules specified by RFC3484. For applications that select a single address, this is usually done by the IPV6_PREFER_SRC_TMP preference flag specified in RFC5014. <del> However, this rule is not completely obvious in the ICE scope.  This is therefore clarified as follows: When a client gathers all IPv6 addresses on a host, and both temporary addresses and permanent addresses of the same scope are present, the client SHOULD discard the permanent addresses before exposing addresses to the application or using them in ICE.  This is consistent with the default policy described in RFC6724. </del> <ins> However, this rule, which iis intended to ensure that privacy- enhanced addresses are used in preference to static addresses, doesn't have the right effect in ICE, where all addresses are gathered and therefore revealed to the application.  Therefore, the following rule is applied instead: When a client gathers all IPv6 addresses on a host, and both non- deprecated temporary addresses and permanent addresses of the same scope are present, the client SHOULD discard the permanent addresses before exposing addresses to the application or using them in ICE. This is consistent with the default policy described in RFC6724. </ins> If some of the temporary IPv6 addresses, but not all, are marked <del> deprecated, the client SHOULD discard the deprecated addresses. </del> <ins> deprecated, the client SHOULD discard the deprecated addresses.  In an ICE restart, deprecated addresses that are currently in use MAY be retained. </ins> 3.4.