Hi Erik I wonder if the simpler fix is simply to replace the word “counterpart” with “analog”.
Eliot > On 27 Sep 2020, at 23:52, Erik Kline <ek.i...@gmail.com> wrote: > > Toerless, > > Thanks for taking the time to go through all this. Generally LGTM, but I > would like to iterate on the ULA text (nothing major). > > > > [ section 2 ] > > > > * "It is the approximate IPv6 counterpart of the IPv4 private address > > ([RFC1918])." > > > > I understand the intent but I don't think this statement is complete. I > > think we shouldn't let this sentence out into the wild as is since it > > could > > be read without any context nor even any pretense of interest in nuance. > > > > May I suggest: > > > > "It is often thought of as the approximate IPv6 counterpart of the IPv4 > > private address space ([RFC1918]), though it is in fact meaningfully > > different in important and subtle ways [and upon which this document > > relies]." > > Thanks for not trying to talk me out of the comparison, which i successfully > used to explain ULA to many customers. Your proposal is a bit too verbose for > the terminoloy section, so it's now: > > It is often thought of as the approximate IPv6 counterpart of the IPv4 > private address (<xref target="RFC1918" format="default"/>). There are > important differences though that are beneficial for and exploited by the > ACP, such as the ULA Global ID prefix, which are the first 48-bits of a ULA > address. In this document it is abbreviated as "ULA prefix". > > It's a statement of fact that this is how people unfamiliar with this space > view this space. It's apparently also a statement of fact that people are > still actively being told this. ;-) > > But I still think it's not quite right. For one, the real counterpart to > 1918 in IPv6 is the deprecated site-local prefix. Also, to say it's "often > thought of" in an IETF document implies more IETF folks think of this way, > when in reality I'm not sure that's the case. > > If you really want to leave this notion in (removing the sentence altogether > is good by me), perhaps we can wordsmith it a bit more. If I may propose: > > OLD: > > ULA: (Global ID prefix) A "Unique Local Address" (ULA) is an IPv6 > address in the block fc00::/7, defined in [RFC4193]. It is often > thought of as the approximate IPv6 counterpart of the IPv4 private > address ([RFC1918]). There are important differences though that > are beneficial for and exploited by the ACP, such as the ULA > Global ID prefix, which are the first 48-bits of a ULA address. > In this document it is abbreviated as "ULA prefix". > > NEW: > > ULA: (Global ID prefix) A "Unique Local Address" (ULA) is an IPv6 > address in the block fc00::/7, defined in [RFC4193]. Sometimes > thought of as the approximate IPv6 counterpart of the IPv4 private > address ([RFC1918]), there are important differences that are > beneficial for and exploited by the ACP. In this document, the > "ULA prefix" refers to Locally Assigned Global ID prefixes, which > are the first 48-bits of the ULA address [RFC4193 section 3.2.1]. > > (I didn't think it was worth trying to get into the fc00::/8 vs fd00::/8 > distinction in this glossary text.) > > > [ section 8.1.3 ] > > > > * Why is an RIO for ::/0 with a lifetime of 0 required? Doesn't it suffice > > it set the default router lifetime to 0? Separately, are all nodes > > required > > to be Type C? > > Check the new text, i hope it explains everything. > > Yes, type A and B do not support per-prefix auto selection of router, > The lifetime of 0 is used so only Type C hosts will invalidate the > default route for the ACP edge node, but not Type A/B hosts. Maybe there > is another parameter combination that achieves this goal, but this was > the easiest for me to assess/describe. > > This looks better, thank you. > > To be honest, I don't know what the point of Type A/B hosts is anymore (and > if it were possible to declare these anima deployments greenfield I would > recommend saying the default router lifetime MUST be zero in the RA header to > force clients to use a stack that works -- but that's just me). > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima
_______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
