Kyle, I think your assessment of this is correct—I too find this terminology awkward to use and always have to think before writing, even though I’m quite experienced with using it. However, this document is not the place to fix that, and indeed I’m not sure how to fix it. Simply switching now would be just as confusing—just to different people.
On Tue, Mar 11, 2025, at 8:44 PM, Kyle Rose wrote:
On Tue, Mar 11, 2025 at 8:45 AM Timothy Winters <tim@xxxxxxxxxx> wrote:- The one thing that stands out is that the document is classified "informational" and yet appears to have a bunch of normative language. Is this intended to be standards track? Or are the requirements established in section 5.1 merely preconditions for the applicability of LDP (akin to RFC 7084's note in section 1.1), in which case I would not regard "MUST" et al. as keywords and would remove the boilerplate in section 2 and/or not use ALL CAPS. (I regard the editorial choice made in the publication of 7084 to be ill-advised because of the potential for confusion given how ALL CAPS normative language is used throughout the rest of the RFC series.)Yes this is a continuation of 7084's Section 1.1. I think it would cause confusion for the update to 7084 to not follow the convention used in it.Fine by me, if that is IETF consensus.Nits: - "Many Service Providers assign prefixes larger then /64 to the CE Router, as recommended in [RFC6177]." If this use of "larger" is idiomatic for IPv6 (i.e., a larger prefix actually means a shorter prefix and therefore more addresses), it is ambiguous to the point that it should be ruthlessly stamped out of the jargon. ("Inflammable means flammable? What a country!")This often causes confusion but it's correct in IPv6 jargon. I may think of a way to reword the sentence to avoid this problem.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":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 strongly recommend that in documentation for IPv6 we refer to "shorter/longer prefix" where the length of the prefix is the primary focus, or to "larger/smaller address block" where the number of addresses is the primary focus, and consign "larger/smaller prefix" to the dustbin of history. If there were ever a terminology debate worth having, this one is it.Kyle_______________________________________________v6ops mailing list -- v6ops@xxxxxxxxTo unsubscribe send an email to v6ops-leave@xxxxxxxx
-- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
