I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments.

This document is Ready. It addresses only terminology, and so has no direct security implications for protocols, though I appreciate and agree with the single Security Consideration: precision in technical documentation is the highest virtue.

To that end, beyond my role as security directorate reviewer I would like to suggest that it might be worthwhile for the IETF as a whole to do some cleanup and take this opportunity to address ambiguities and poorly-chosen terminology more broadly. To quote my email to v6ops from March 11, 2025 (https://mailarchive.ietf.org/arch/msg/last-call/pVwoMNgOf2CJ7CnGU5LENRoV8Ts/) regarding "larger/smaller prefix":

> This is the one hill in this review I'm going to die on, and this feedback is not directed only to you or about only this draft, but is broadcast to 6man and to the entire IETF more generally. This jargon is ambiguous and actively confusing to noobs, and we should stop using it in official documents. Erik Nygren helpfully posted a poll on his Mastodon cell or pod or whatever it is, and last I checked nearly a quarter of the responses were either counter to the expert understanding or explicitly "unsure":
> 
> https://hachyderm.io/@nygren/114145161861032281
> 
> What makes this case pessimal from a comprehensibility standpoint is that the term means precisely opposite things depending on your level of context: if you are generally familiar with computer science or math, "larger prefix" means "more specified octets", while if you are an IPv6 weenie, "larger prefix" means "more addresses". Notably, IPv4 does not have this problem because people generally refer to a "larger netblock" or "larger subnet" or "larger CIDR block", not "larger prefix" since prefixes aren't a thing in IPv4 jargon.

I'm absolutely sure there is a ton of crap like this that should get cleaned up. Dedicating an RFC to each case seems inefficient: an SDO-wide request for clarifications of this sort could feed into a single RFC with recommendations, followed by submissions of errata to documents that don't align with the new guidelines. That might prove a better use of IETF-wide attention span.