Last Call Review of draft-ietf-isis-reverse-metric-13
review-ietf-isis-reverse-metric-13-secdir-lc-leiba-2018-10-04-00

Request Review of draft-ietf-isis-reverse-metric
Requested rev. no specific revision (document currently at 16)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2018-10-17
Requested 2018-10-03
Other Reviews Genart Last Call review of -15 by Stewart Bryant (diff)
Rtgdir Telechat review of -15 by Harish Sitaraman (diff)
Review State Completed
Reviewer Barry Leiba
Review review-ietf-isis-reverse-metric-13-secdir-lc-leiba-2018-10-04
Posted at https://mailarchive.ietf.org/arch/msg/secdir/EtsjkuvMT3J_sgtToTr7pd9ylHc
Reviewed rev. 13 (document currently at 16)
Review result Ready
Draft last updated 2018-10-04
Review completed: 2018-10-04

Review
review-ietf-isis-reverse-metric-13-secdir-lc-leiba-2018-10-04

This document is well written and seems ready to go.  The only security issue I thought of as I read through it (attacking by spoofing a reverse metric) is covered in the Security Considerations section.

I found one sentence to be slightly ambiguous, but only very slightly.  In Section 3.5:

   A router MUST advertise a Reverse Metric TLV toward a neighbor only
   for the operational maintenance window period during which it wants a
   neighbor to temporarily update its IS-IS metric or Traffic
   Engineering parameters towards it.

It begins to look like it's saying that a router MUST advertise this under certain conditions, and it took me a moment to get that it's actually *limiting* when it should be advertised (the "MUST" applies to the "only" clause).  If you think my suggested replacement reads well, you might use it; if not, no problem:

   A router MUST limit the period during which it advertises a Reverse Metric
   TLV toward a neighbor only to the operational maintenance window period
   during which it wants that neighbor to temporarily update its IS-IS metric
   or Traffic Engineering parameters towards it.