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 >