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

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

 



Thank You! :)

On 30/01/18 04:53, "Qin Wu" <bill.wu@xxxxxxxxxx> wrote:

>Thanks Christer, you address my comments.
>
>-Qin
>-----邮件原件-----
>发件人: Christer Holmberg [mailto:christer.holmberg@xxxxxxxxxxxx]
>发送时间: 2018年1月29日 16:56
>收件人: Qin Wu; ops-dir@xxxxxxxx
>抄送: draft-ietf-ice-rfc5245bis.all@xxxxxxxx; ietf@xxxxxxxx; ice@xxxxxxxx
>主题: Re: Opsdir last call review of draft-ietf-ice-rfc5245bis-16
>
>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]