[Last-Call] Re: [v6ops] Re: Secdir last call review of draft-ietf-v6ops-cpe-lan-pd-06

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Mar 11, 2025 at 5:31 PM Ted Lemon <mellon@xxxxxxxxx> wrote:
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. 

Ted, I'm not suggesting we put this I-D on hold to publish an RFC explaining the problem and prescribing more precise terminology, or that we immediately -bis every IPv6-related document to clarify terminology. I'm merely advocating that, starting now—with this document—that we replace the ambiguous phrase with an unambiguous phrase. I fail to see how doing this would pose any real barrier to publication, impose any real burden for the author or the working group, or be confusing to experts who already interpret the ambiguous phrase in the same way that everyone would interpret the unambiguous phrase.

Here's my proposal for this particular document:

q( Many Service Providers assign address blocks larger than /64 to the CE Router, as recommended in [RFC6177]. If an IPv6 CE Router does not support the Identity Association for Prefix Delegation (IA_PD) Prefix Option ([RFC8415]) on the LAN it will not be able to assign any prefixes beyond its local interfaces, limiting the usefulness of assigning address blocks larger than /64 by the operator. )

Note that RFC 6177 itself does not talk about larger "prefixes", only about larger "[address] blocks".

Kyle

-- 
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux