[dhcwg] Re: Secdir last call review of draft-ietf-dhc-addr-notification-11

[Jen Linkova <[e-mail]>]

Hi Peter,

Thank you for your feedback and text suggestions!

On Wed, May 1, 2024 at 2:46 PM Peter Yee via Datatracker
<[e-mail]> 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