I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
Please resolve these comments along with any other Last Call comments
you may receive.
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.
Kind regards,
- Christian
_______________________________________________
Gen-art mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/gen-art
