Ballot for draft-ietf-ice-dualstack-fairness
Yes
No Objection
Note: This ballot was opened for revision 04 and is now closed.
The draft has been repeat-last called as a BCP
Thanks for doing this work. The document thinks it's going for Best Current Practice, but the shepherd write-up and datatracker think it's going for Informational. It would be good for that to match ... I'm a little confused by These recommendations are backward compatible with a standard ICE implementation. The resulting local and remote checklist will still be synchronized. The introduced fairness might be better, but not worse than what exists today Is the point that the introduced fairness - might be better, or - might be the same as, but - won't be worse? If so, that wasn't clear to me on first (or second) reading. (Nit: missing period at the end of "what exists today")
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