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. This document is ready with issues. In general, I think the document does a reasonable job of describing some of the threats associated with OLSRv2. There are some places where the document could be clearer and there are some additional variations threats the authors may wish to consider. One issue that I did not see discussed in the draft would be for the attacker to effectively delay packets. For example, the attacker captures packets while jamming to prevent some stations from receiving packets. The attacker can collect a sequence of traffic and replay at a later time, with different timing and in a different location. Not all replay mechanisms will defend against this attack int he same way. Sequence number validation (which appears to be allowed in 7183) may not be as effective as timestamps, depending upon the time skew allowed. The document does discuss timestamps , but I think it should probably make the following clearer: There are several places in sections 4 and 5 where the document says something like "This kind of attack can be mitigated using integrity check mechanisms". I think in most of these instances replay protection is also important. One solution would be to remove these instances and just relay on section 6.2 which has a better description of the available protections. Since it seems that the integrity check could be deployed with just sequence number instead of timestamps it might be good to mention that it is important to include and verify timestamps for replay protection. Thanks, Joe