Subject: [Ice] Alissa Cooper's No Objection on draft-ietf-ice-dualstack-fairness-05: (with COMMENT)

From: "Alissa Cooper" <[email-masked]>
Date: Tue, 04 Oct 2016 10:50:59 -0700

Alissa Cooper has entered the following ballot position for
draft-ietf-ice-dualstack-fairness-05: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ice-dualstack-fairness/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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.