Document:  draft-ietf-mmusic-ice-17.txt
Reviewer:  Christian Vogt
Review Date:  August 16, 2007
IETF LC End Date:  August 13, 2007


Summary:

This document is of very good quality.  It also has a very plausible problem statement 
and an excellent summary of the ICE operation.  I support this document going forward 
in the publication process.


Comments:

A few comments still, but they are easy to fix:

(1)  Section 2.6, 1st paragraph:

                             However, it is possible that packet
  losses will cause a higher priority check to take longer to complete.
  In that case, allowing ICE to run a little longer might produce
  better results.

  Just to avoid confusion:  I would say "a packet loss" rather than
  "packet losses".  A reader might otherwise wonder why running "a
  little longer might produce better results" if it would mean that
  a high-packet-loss path gets eventually chosen.

(2)  Regarding the Security Considerations section:

Section 18.5.2, "STUN Amplification Attack", explains that ICE candidate probes could 
be used for amplified flooding:

   It is impossible to eliminate the amplification, but the volume can
   be reduced through a variety of heuristics.  [...]

A reader might at first glance wonder why the amplification could not be avoided by 
requiring the initiator to send a separate request per response.  E.g., this is done in
 Mobile IPv6 route optimization where a mobile host sends out two initialization messages
 that each prompt the peer to send a single response message.

It might hence be valuable to note in section 18.5.2 that a "balancing"
of the number of request and response messages is not possible in the case of ICE 
because the initiator does not know the number of responses at the time it sends the 
request.  In ICE, the number of responses depends on both the initiator's and 
the responder's set of IP addresses.

(3)  Finally some editorial notes:

Section 2.1, 1st paragraph:

                                                  In all cases, such
  a network interface appears to the agent as a local interface from
  which ports (and thus a candidate) can be allocated.

  s/ports (and thus a candidate)/a port (and thus a candidate)/
  ...or plural in both cases.

Section 2.1, 2nd paragraph on page 11:

  I assume "local interface Y" should be "local IP address Y" because
  only the IP address is relevant for connectivity, not the interface.
  And an interface may have multiple IP addresses, of course.