Last Call Review of draft-ietf-pals-ple-09
review-ietf-pals-ple-09-tsvart-lc-pauly-2024-10-18-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
[email protected] 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"