Skip to main content

Guidelines for Multihomed and IPv4/IPv6 Dual-Stack Interactive Connectivity Establishment (ICE)
draft-ietf-ice-dualstack-fairness-07

Yes


No Objection

(Deborah Brungard)
(Jari Arkko)
(Terry Manderson)

Note: This ballot was opened for revision 04 and is now closed.

Ben Campbell Former IESG member
(was Discuss, Yes) Yes
Yes (2016-12-22) Unknown
The draft has been repeat-last called as a BCP
Spencer Dawkins Former IESG member
Yes
Yes (2016-08-30 for -04) Unknown
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")
Alissa Cooper Former IESG member
(was Discuss) No Objection
No Objection (2016-10-04 for -05) Unknown
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.
Alvaro Retana Former IESG member
(was Discuss) No Objection
No Objection (2016-09-01 for -04) Unknown
[Clearing my DISCUSS, as Ben will LC again with the correct status.]
Deborah Brungard Former IESG member
No Objection
No Objection (for -04) Unknown

                            
Jari Arkko Former IESG member
No Objection
No Objection (for -04) Unknown

                            
Kathleen Moriarty Former IESG member
No Objection
No Objection (2016-08-30 for -04) Unknown
Thanks for addressing the SecDir comments:
https://www.ietf.org/mail-archive/web/secdir/current/msg06670.html
Mirja Kühlewind Former IESG member
(was Discuss) No Objection
No Objection (2016-11-02 for -06) Unknown
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."
Stephen Farrell Former IESG member
No Objection
No Objection (2016-09-01 for -04) Unknown
This already has a fair number of discusses:-)
Suresh Krishnan Former IESG member
(was Discuss) No Objection
No Objection (2016-09-21 for -05) Unknown
Thanks for addressing my DISCUSS points and COMMENTs
Terry Manderson Former IESG member
No Objection
No Objection (for -04) Unknown