Reviewer: Tommy Pauly Review result: Ready with Nits 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. First, as a comment on readability: this document (even for an IETF document!) has some particularly dense acronyms and terms! :) I appreciate the detailed terminology section, but have a couple comments on possible improvements. - In general, acronyms used before the terminology section are indeed written out, which is great, but there are some missing like "CE" and "PE". Please define such terms on first use! - Where possible, it would be useful to add RFC references for some of the terms so more detailed definitions can be read. This might be useful on the applicable entries in the terminology section. With regards to transport, much of this document is discussing a virtual layer to represent non-packet-switched link, so many normal transport recommendations might not apply. This is acknowledged by the document. I think that section 8, "QoS and Congestion Control", could potentially benefit from more up-to-date references and recommendations for how the underlying packet-switched network can achieve the lowest loss and jitter. The current text is pointing to RFC 2475 for diffserv and asking to reserve a traffic-engineered path. I wonder if the layers that are detecting loss or reordering (at the PLE encapsulation layer, from my understanding) could benefit from marking like those used for L4S (RFC 9330). At the least, it would be good to have a bit more discussion in this section about the overall impact of loss or reordering on the underlying network, and what impact that does have on the virtual link. Nit: I think "Physical Subcoding Layer (PCS)" is the wrong definition, it should be the same as "PCS - Physical Coding Sublayer" -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
