Last Call Review of draft-ietf-lsr-isis-rfc7810bis-03
review-ietf-lsr-isis-rfc7810bis-03-tsvart-lc-nishida-2018-12-05-00

This document has been reviewed as part of the transport area review team's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the document's
authors and WG to allow them to address any issues raised and also to the IETF
discussion list for information.

When done at the time of IETF Last Call, the authors should consider this
review as part of the last-call comments they receive. Please always CC
tsv-art@ietf.org if you reply to or forward this review.

Summary: This document is almost ready for publication, but several points need
to be clarified.

1: In Section 1:
     "While this document does not specify how the performance information
     should be obtained, the
      measurement of delay SHOULD NOT vary significantly based upon the offered
      traffic load."

   It is not clear to me that why the measurement of delay should not vary
   here. Also, queuing delay might be useful info to infer path status. Could
   you elaborate the delays that the draft tries to capture?

2: In Section 1:
     "Thus, queuing delays SHOULD NOT be included in the delay measurement. "

   Is it clear for expected readers how to exclude queuing delays in their
   measurements? Don't we need to provide any guidances or references here?
   Also, what they should do if they cannot exclude it?

3: In Section 2:

     "All values (except residual bandwidth) MUST be calculated as rolling
     averages where the
      averaging period MUST be a configurable period of time."

   This requirement is a bit different from the following texts in Section 5:
   Also, does this mean only simple moving average must be used or any forms of
   moving average is acceptable?

    "The values advertised in all sub-TLVs (except min/max delay and
     residual bandwidth) MUST represent an average over a period or be
     obtained by a filter that is reasonably representative of an average.
     For example, a rolling average is one such filter."

4: In Section 4.3:

    "This sub-TLV advertises the average link delay variation between two
     directly connected IS-IS neighbors.  The delay variation advertised
     by this sub-TLV MUST be the delay from the local neighbor to the
     remote one (i.e., the forward-path latency)."

   Sorry.. I am not sure how to measure delay variation here. I think more
   explanation is needed. It seems that it is not variance as the unit is sec.

5: In Section 11:

    "The use of Link State PDU cryptographic authentication allows mitigation
    the risk of man-in-
     the-middle attack."

   When there is a risk for man-in-the-middle attack, don't we need more strong
   requirements for the use of security mechanisms?

Thanks,
--
Yoshi