Guidelines for Multihomed and IPv4/IPv6 Dual-Stack Interactive Connectivity Establishment (ICE)
RFC 8421

Thanks for addressing my DISCUSS.

Previous COMMENT:

= Section 3 =

"If the agent has access to
   information about the physical network it is connected to (Like SSID
   in a WiFi Network) this can be used as information regarding how that
   network interface should be prioritized at this point in time."

I think this needs further elaboration, as it's not obvious how knowledge of the SSID correlates to knowledge of the stability of the network.

"Candidates from an interface known to the application to provide
   unreliable connectivity should get a low candidate priority.  This
   ensures they appear near the end of the candidate list, and would be
   the last to be tested during the connectivity check phase.  This
   allows candidate pairs more likely to succeed to be tested first."

All three of these sentences say more or less the same thing, so two of them could be dropped.

= Section 8 =

Doesn't following the recommendations in Section 3 potentially leak information to a remote peer about the quality of a local peer's connectivity on different interfaces? That is, if the remote peer maintains some state about past ICE interactions, would it be able to detect a change of priority that could indicate a change in connectivity quality? If so, this seems worth mentioning.

[Clearing my DISCUSS, as Ben will LC again with the correct status.]

Thanks for addressing the SecDir comments:
https://www.ietf.org/mail-archive/web/secdir/current/msg06670.html

Thanks for addressing my comments and also not talking about fairness anymore. There are some more concrete recommendations now but some are still vague. 

I would still like to proposed the following addition to the intro:

OLD:
"To avoid such user noticeable delays when either IPv6 or IPv4 path is
   broken or excessively slow, this specification encourages
   intermingling the different address families when connectivity checks
   are performed.  This will lead to more sustained dual-stack IPv4/IPv6
   deployment as users will no longer have an incentive to disable IPv6.
   The cost is a small penalty to the address type that otherwise would
   have been prioritized."

NEW:
"To avoid user noticeable delays when either IPv6 or IPv4 path is
   broken or excessively slow, this specification encourages
   intermingling the different address families when connectivity checks
   are performed.  This will lead to more sustained dual-stack IPv4/IPv6
   deployment as users will no longer have an incentive to disable IPv6.
   The cost is a small penalty to the address type that otherwise would
   have been prioritized. Further this document recommends to keep
   track of previous known connectivity problem and assign a lower 
   priority to those addresses."

Maybe even add:
"Tracking connectivity is a question on its own and out of scope for
   this document."

This already has a fair number of discusses:-)

Thanks for addressing my DISCUSS points and COMMENTs