Reviewer: Yoshifumi Nishida
Review result: Almost Ready
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@xxxxxxxx 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
