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.

This document is Ready with Issues.

The only issue I will note with this scheme is one that I'm sure has been litigated to death on the mailing list, and that may be unresolvable within the bounds of technically-permissible but unobserved reordering behavior on networks: that packets will be delivered more-or-less in-order to receivers within each category (unicast and multicast). If that is true in practice, and especially if it is a property that network device vendors already have as an explicit requirement when implementing packet handling queues, then it's probably fine to note that clearly, and maybe to explain the reasoning behind the RECOMMENDED vs. OPTIONAL mitigations in section 1.

I am frankly more concerned that RFCs 7298 and 8967 both made it to publication with only one mention of the word "reordering" between them, perhaps suggesting a lack of vendor attention to, or knowledge of, the work being done in this space. Given the near complete absence of any normative prohibition against packet reordering in datagram handling, this oversight may reflect insufficient prior outreach to subject matter experts that should be noted and corrected by ADs in future work for which packet handling behavior by on-path devices is of critical importance to protocols being developed.

Other notes:

Section 3.1.1. If the problem with maintaining more queues is that the 4-tuple comprises "the only fields...protected by the MAC", a natural solution might be to protect that field, as well. I'm not suggesting that is desirable; rather, I note there is no discussion in this draft, or in RFC 8967, discussing the motivation behind the choice of header fields to protect with the MAC.

Nits: there is an HTML entity rendered as literal text ("Gröber") in the Acknowledgements section of the HTML I am reading (https://www.ietf.org/archive/id/draft-ietf-babel-mac-relaxed-04.html). Make sure to follow tools guidance for encoding non-Latin characters in drafts.