Hi, I have re-reviewed this document. Overall, a lot of very good changes have been made. I appreciate the additions to the Security Considerations section. Both of those are well written and give appropriate guidance. I went back and re-read what I had asked about discussing multicast as a malicious attack vector. My apologies, but I didn't make myself clear. I was asking about what would happen if a device on the Internet were to start sending multicast packets to the 6LBR attempting to get it to forward them to the 6LNs. I'm thinking that would cause a great deal of overhead processing on the 6LBR and perhaps overwhelm the Bluetooth network. Is there a way to prevent or mitigate that? Best regards, Chris On 6/3/15 6:23 PM, Chris Lonvick wrote: Hi, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Overall, the document is well written and explains the concepts well. I saw that a "test interface" is defined in Section 2.1. I would like to see some guidance in the Security Considerations section about this. Hopefully the guidance will describe how the interface is secured, or that it can be secured by an operator. Multicast is mentioned several times throughout the document mostly saying that the Bluetooth LE link layer does not support it. I would like to see this addressed in the Security Considerations section as well to alert implementers and operators that this may be a point of attack. Any guidance on how to prevent an active, malicious denial of service attack using multicast would be appreciated.