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