Last Call Review of draft-ietf-manet-olsrv2-metrics-rationale-02
review-ietf-manet-olsrv2-metrics-rationale-02-secdir-lc-kent-2013-03-07-00

Request Review of draft-ietf-manet-olsrv2-metrics-rationale
Requested rev. no specific revision (document currently at 04)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2013-03-11
Requested 2013-02-28
Draft last updated 2013-03-07
Completed reviews Genart Last Call review of -02 by Suresh Krishnan (diff)
Genart Telechat review of -03 by Suresh Krishnan (diff)
Secdir Last Call review of -02 by Stephen Kent (diff)
Assignment Reviewer Stephen Kent
State Completed
Review review-ietf-manet-olsrv2-metrics-rationale-02-secdir-lc-kent-2013-03-07
Reviewed rev. 02 (document currently at 04)
Review result Has Issues
Review completed: 2013-03-07

Review
review-ietf-manet-olsrv2-metrics-rationale-02-secdir-lc-kent-2013-03-07



SECDIR review of
        draft-ietf-manet-olsrv2-metrics-rationale-02




 




I 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 targeted
        as an Informational RFC. It describes itself as “… an historic
        record of the
        rationale for, and design considerations behind, how link
        metrics were included
        in OLSRv2.”




 




The Security
        Considerations section says simply “This document does not
        specify any security
        considerations.” It’s been a very long time (many years) since
        I’ve encountered that
        phrase in a candidate RFC. A rationale document itself probably
        does not entail
        security considerations, but the omission of any security
        discussion suggests
        that security did not play a role in the deign of this routing
        protocol. Is
        that true? If so, who thinks this is a good thing?




 




I looked at
        the I-D that
        defines OLSRv2. It contains a two-page Security Considerations
        section. From my perspective, this document ought to provide
        background info (rationale) for the security
        suggestions contained that document.