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

Request Review of draft-ietf-lsr-isis-rfc7810bis
Requested rev. no specific revision (document currently at 05)
Type Last Call Review
Team Transport Area Review Team (tsvart)
Deadline 2018-12-12
Requested 2018-11-28
Draft last updated 2018-12-05
Completed reviews Secdir Last Call review of -03 by Roman Danyliw (diff)
Genart Last Call review of -03 by Paul Kyzivat (diff)
Tsvart Last Call review of -03 by Yoshifumi Nishida (diff)
Assignment Reviewer Yoshifumi Nishida
State Completed
Review review-ietf-lsr-isis-rfc7810bis-03-tsvart-lc-nishida-2018-12-05
Reviewed rev. 03 (document currently at 05)
Review result Almost Ready
Review completed: 2018-12-05

Review
review-ietf-lsr-isis-rfc7810bis-03-tsvart-lc-nishida-2018-12-05

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