I have reviewed this document as part of the Operational directorate’s ongoing effort to review all IETF documents being processed by the IESG.  These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review.  Document editors and WG chairs should treat these comments just like any other last call comments.
Document reviewed:  draft-ietf-ice-rfc5245bis-16

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.

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

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?

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