I've been selected as the secdir reviewer for this draft. These comments are intended for the security ADs (and other ADs); authors please treat them as any other last call comments. I have one major issue. This draft is sufficiently unclear in its introductory material that I found it very challenging to review. What it's trying to do is to specify behavior for handling of ICE by B2BUAs. However, the introduction never says that; the introduction talks a lot about the background for B2BUAS, ICE, STUN and related parts of the SIP infrastructure. Coming back to reading SIP documents after a number of years, the bibliography provided in the introduction was useful, but the introduction needs to describe what this document does. The abstract sort of tries to describe what the document does. However, our process requires that the document and abstract stand independent of each other. The reader cannot be expected to read the abstract before reading the document. Also, the abstract claims that this document specifies the handling of STUN messages inside ICE. Section 3 and 4 actually provide requirements for handilg of SDP attributes, ICE processing and other things far beyond handling of STUN messages. My recommendation for addressing this issue is: 1) Update the abstract to make it clear that this is overall requirements for B2BUAs interacting with ICE, not just requirements for handling STUN messages. 2) Make sure everything the abstract says is near the front of the introduction. After introducing what STUN, ICE, and B2BUAs are, it's important to explain the role of this document. Once I understood what this document was trying to do I was able to think about the security implications. There really don't seem to be any new security implications with this document. The security considerations section is fairly lite, but the introduction does point to the existing discussions of security of ICE and B2BUAs and various latching techniques. I don't think this protocol introduces or even really changes the security landscape. It gives guidance which if followed will mean that good actors don't break the security mechansisms. That is valuable because if the frequency of good actors breaking security mechanisms is low enough, we can actually rely on the security mechanisms. So, I think the security considerations section is fine as-is, although the security ADs may wish to ask for a couple of references to be copied from the introduction.