Re: Opsdir last call review of draft-ietf-ice-rfc5245bis-16

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Qin,

Thank You for the review! Please see inline.

>Summary:
>This document defines ICE protocol for NAT traversal in the UDP-based
>communication. The draft is well written, especially operational
>consideration
>section and security section. I believe it is ready for publication.
>
>Major issue: None
>Minor issue: Editorial
>1.This draft discuss the difference between ICE and ICE difference in many
>places, e.g., ³ 17.3.  ICE and ICE-lite
>
>   Deployments utilizing a mix of ICE and ICE-lite interoperate
>   perfectly.  They have been explicitly designed to do so, without loss
>   of function.
>³
>³
>4.  Terminology
>
>   Full Implementation:  An ICE implementation that performs the
>      complete set of functionality defined by this specification.
>
>   Lite Implementation:  An ICE implementation that omits certain
>      functions, implementing only as much as is necessary for a peer
>      implementation that is full to gain the benefits of ICE.  Lite
>      implementations do not maintain any of the state machines and do
>      not generate connectivity checks.
>³
>³
>Appendix A.  Lite and Full Implementations
>
>   ICE allows for two types of implementations.  A full implementation
>   supports the controlling and controlled roles in a session, and can
>   also perform address gathering.  In contrast, a lite implementation
>   is a minimalist implementation that does little but respond to STUN
>   checks.
>³
>I would suggest to make them consistent, e.g., in section 17.3, it
>mentions
>that deploying combination of ICE and ICE-Lite can be designed to
>interoperate
>perfect without loss of function, however ICE-Lite in section 4 is
>defines as
>one implementation that could omit some of function.

I think the ³without loss of function² part is a little misleading, as the
lite implementation will not perform certain tasks.

I suggest to simply say:

 "Deployments utilizing a mix of ICE and ICE-lite interoperate
  perfectly.  They have been explicitly designed to do so."


>Also I want to know whether lite implementation supports the controlling
>and
>controlled roles in Appendix A.

I suggest to modify the following sentence:

OLD:

   "In contrast, a lite implementation is a minimalist implementation that
does little but respond to STUN
    checks.²


NEW:

   "In contrast, a lite implementation only is a minimalist implementation
that does little but respond to STUN
    Checks, and only supports the controlled role in a session.²


---


>2. Section 17.2.2 said:
>"
>The gathering phase and the connectivity
>   check phase are meant to generate traffic at roughly the same
>   bandwidth as the data traffic itself.
>"
>"
>   Of course, the ICE
>   checks will cause a marginal increase in the total utilization;
>   however, this will typically be an extremely small increase.
>"
>I am wondering whether generated traffic in the first sentence is
>referred to
>connectivity check signaling traffic+ gathering signaling traffic+ user
>data
>traffic, in other words, whether connectivity check signaling traffic+
>gathering signaling traffic can be ignored comparing with the total
>volume of
>data traffic?


The intension is to say that the ICE process (gathering and connectivity
check) will not consume more bandwidth than, once ICE has concluded, the
data itself.

Would the following modified sentence be more clear?

 "The gathering phase and the connectivity check phase are meant to
generate traffic at roughly the same
  bandwidth as the data traffic itself will consume once the ICE process
conclude.²


I also think the second sentence could be clarified:

 ³Once ICE has concluded, the subsequent ICE keep-alives will later cause
a marginal increase in the total bandwidth utilization;
  however, this will typically be an extremely small increase."


---

>3. Section 19.4.1 said:
>³
>19.4.1.  STUN Amplification Attack
>
>   he STUN amplification attack is similar to a "voice hammer" attack,
>³
>s/he STUN amplification attack/The STUN amplification attack


Will fix as suggested.

Regards,

Christer





[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]