I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair.  Please treat these comments just like any other last call comments. For more information, please see the FAQ at ;. Document: draft-ietf-manet-olsrv2-sec-threats-03.txt Reviewer: Elwyn Davies Review Date: 2016/12/18 IETF LC End Date: 2016/12/20 IESG Telechat date: 2017/01/05 Summary: Ready with nits Major issues:  None. Minor issues: s3.2:  I do not know enough about the details of NHDP and OLSRv2 to know if this is a silly question:  Would it be possible for a compromised node to perform hop-limit or hop-count modification attacks even with RFC 6183 security in place just by modifying these fields and reforwarding the packet even if it wasn't actually in the network topology?   If so, it would be desirable to mention this if it can do any harm. s6:  I am unclear whether the RFC 6183 security mitigates all the threats mentioned  here and in RFC 7186.  It would be useful to list any that remain unmitigated at the end of s9 as items for further study (or say that all of these are covered).    Nits/editorial comments: idnits indicates that RFC 6779 has been obsoleted by RFC 7939.  I think this ref ought to be updated. I noticed that Ian Chakeres' affiliation is out of date. Abstract: s/threats of/threats that might apply to/ s1, para 2: s/requirements presented/requirements that need to be addressed / s1, para 2: s/utopia/utopian/ s1, para 2: OLD:    For the    Internet, with an increase in users, an increase in attacks and    abuses followed necessitating a change in recommended practices. NEW:    With deployent in the wider     Internet, with a resultant increase in user numbers, an increase in attacks and    abuses has followed necessitating a change in recommended practices. ENDS s1, para 3: s/often is/is often/ s1, para 3: s/particular/greater/  s1, para 3: OLD: there is commonly no physical    protection as otherwise known for wired networks. NEW: there are commonly no physical constraints on the conformation of nodes and     communication links that make up the network as could be expected for    wired networks. ENDS s1, para 4: s/secured/well-secured/ s1, para 2: s/to OLSRv2/of OLSRv2 s1,next to last para: It would be good to reference RFC 6130 for NHDP here. s1.1, para 1: OLD: Link State Advertisements, They are described in the    below with sufficient details for elaborating the analyses in this    document. NEW: Link State Advertisements. They are described in the sections    below with sufficient details to allow elaboration of the analyses in this    document. ENDS s1.3: s/correctly looking/apparently correct/ s1.4; s/henceforth/henceforth identified as/ s1.3: s/disrupt the the LSA process,/disrupt the LSA process,/ s3, para 1: s/TCs to not being delivered to/TCs not being delivered to/ s3.1, para 1: s/a jittering/a jittering mechanism/ s3.2.1, para 1: s/forwarding the message/forwarding for the message/ s3.2.1, para 2: s/transmissions arrives/transmissions arrive/ s4.3.1, s4.3.2 and s5.1:  The statements that 'this threat can be mitigated...' are premature and belong to s6.  Suggest removing the sentences. s4.4, para 6:  OLD: The compromised OLSRv2 router will indicate its willingness to be zero (thus, avoid being selected as MPR) NEW: The compromised OLSRv2 router will indicate its willingness to be selected as an MPR as zero (thus, avoid being selected as MPR) ENDS s5.1, para 1: OLD: The inconsistent topology maps due to neighborhood discovery has been NEW: The creation of inconsistent topology maps due to neighborhood discovery has been ENDS s6.2.1, "Modifying the hop limit/count": I think you mean "mutable" rather than "mutual" (2 places)! s6.2.3, "Identity Spoofing": s/may further allow to revoke/may give the possibility of revoking/ s9: There is some discussion as to whether an Informational RFC can have Normative References.  I think it shouldn't, but if it does then I would argue that RFC 6130 and RFC 7183 are also normative.