Reviewer: Kyle Rose
Review result: Ready with Issues
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.
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.
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
