Reviewer: Gorry Fairhurst 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. / Review: https://datatracker.ietf.org/doc/draft-ietf-v6ops-ipv6-ehs-packet-drops/?include_text=1 —— This draft examines ops issues associated with IPv6 EHs. The document is well-written, with an operational/security bias. The transport area interest is primarily as a user of the potential to use an EH, and how an EH might impact the probability of packet delivery to an endpoint. * The ID discusses the current issues that result in EH filtering: In this respect, the document describes challenges and mitigations based on experience - and concludes: “This document is not a recommendation to drop such packets, but rather an analysis of why they are dropped”. However there is one sentence where the text could potentially be mis-read as offering new IETF advice, which if misread, could suggest there is no potential for a future transport to use this, which I don’t read as the intention: /As a result, operators usually drop IPv6 packets containing this extension header. / - There are various ways you might consider rewording this. One way could be to say something more like “As a result, many operators currently drop” * The ID also discusses use of the IPv6 Flow Label: This seems a little off topic, but seems linked to EH implications on ECMP. However, the final sentence of this section is a reference to [Jaeggli-2018] which in turn concludes that the IPv6 Flow Label should not be used it as a part of hashes for load balancing. Yet, as far as I know, this is not the recommendation of the IETF in 2020. This seems therefore to be an odd concluding sentence for a section that seems otherwise to support the IETF recommendations. - This might perhaps be easily made more neutral by moving the sentence that affirms the IETF RFCs. i.e., moving the sentence starting “Clearly,…” to become the last sentence in that section. —-- The remaining comments are not linked to paths, and are editorial comments/NiTs: * Maybe the double parenthesis could be just ‘[‘ and ‘]’ rather than “([“ and “])”? * Reading: /(and formally forbids such fragmentation case)./ - readability could improve by removing /case/ * A definition would be helpful for /RLDRAM/. * There are many types and sizes of routers, is this true of all routers (including low-end) or could this better reflect some type of routers? So, maybe the following statements could use better words than /most contemporary routers/? /Most contemporary routers use dedicated hardware/ … and later: /Most contemporary routers have a fast hardware-assisted forwarding plane/ * I suggest a more powerful chip design might not have reduced performance, but would cost more: /but the overall performance of the system will be reduced. / - so maybe either performance is reduced or the system cost increased? * Insert "forward": /to make a decision regarding which of the links to use for a given packet./ - to /use for/to use to forward/ * Typo: / Use of unknown extension headers can prevent an NIDS/IPS from processing layer-4 information/ - Add a period after, to match other items in the same list. -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
