Hi Peter, Thank you for your feedback and text suggestions! On Wed, May 1, 2024 at 2:46 PM Peter Yee via Datatracker <noreply@xxxxxxxx> wrote: > Page 6, 3rd paragraph after Figure 3, 1st sentence: Presumably the IA Address > option is inside of an IA_NA or IA_TA option as required by RFC 8415, section > 21.6. Should this be spelled out? No, the IA Address option will appear by itself, since the other fields of the IA_NA and IA_TA options wouldn’t really be given any reasonable values and are not really applicable. The must in RFC 8415, section 21.6 is not normative language (it’s not an uppercase MUST). Also, it’s not clear that the text of that section prohibits putting an IA option in other options. It’s possible to read the text as saying, “in an IA_NA option it must be in the IA_NA-options field, and in an IA_TA option it must be in the IA_TA-options field”. We can make it explicit. We can also make this draft to update RFC8415 (or the -bis, which is the WGLC) and allow the IA Address option to appear in the registration message by itself. Page 11, section 4.6, 2nd paragraph, 3rd sentence: you might want to indicate that the range is inclusive (as implied by the 3rd bullet item on the next page). You might also want to give a useful precision needed across this range to offer a reasonable desynchronization effect. Otherwise, choosing to use a single digit after the decimal point meets the requirement but only provides 3 multiplier values. I have no idea how much desynchronization is required, but I’m guessing this is network dependent. > Page 11, section 4.6, 2nd paragraph, 3rd sentence: >you might want to indicate that the range is inclusive (as implied by the 3rd bullet item on the next page). >You might also want to give a useful precision needed across this range > to offer a reasonable desynchronization effect. Otherwise, choosing to use a > single digit after the decimal point meets the requirement but only provides 3 > multiplier values. I have no idea how much desynchronization is required, but > I’m guessing this is network dependent. We've updated the text to say “uniformly distributed”. So the sentence now read: "AddrRegDesyncMultiplier is a random value uniformly distributed between 0.9 and 1.1 (inclusive) and is chosen by the client when it starts the registration process, to ensure that refreshes for addresses with the same lifetime are coalesced (see below)." This is consistent with the wording used by other documents (e.g., RFC 4861), and it implies that every value that the client is able to represent has equal probability. Because no client will have less than floating-point granularity to represent decimal numbers, the value should be well desynchronized even if we do not explicitly specify the precision. -- Cheers, Jen Linkova -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
