Re: [dhcwg] WGLC for draft-ietf-dhc-rfc8415bis / clarification of significant prefix change

[Tomek Mrugalski <[e-mail]>]

On 1.02.2024 15:44, Esko Dijk wrote:
> Hello Tomek,
> ...
> I've made a proposal for the text below (will also add this to the Github PR comments). The "Confirm/Reply" exchange is added based on your last response - it wasn't in the original text. So we should keep in mind that this is changing the original "SHOULD" requirement.
> 
> OLD: 
> 
> If not associated with one of the above-mentioned conditions, a client SHOULD initiate a Renew/Reply exchange (as if the T1 time expired) as described in Section 18.2.4 or an Information-request/Reply exchange as described in Section 18.2.6 if the client detects a significant change regarding the prefixes available on the link (when new prefixes are added or existing prefixes are deprecated), as this may indicate a configuration change. However, a client MUST rate‑limit such attempts to avoid flooding a server with requests when there are link issues (for example, only doing one of these at most every 30 seconds).
> 
> NEW:
> 
> If not associated with a detection of having moved to a new link, a client SHOULD initiate one of the Renew/Reply, Confirm/Reply or Information-request/Reply exchanges, if the client detects a significant change regarding the prefixes available on the link. A change is considered significant when one or more on-link prefixes are added, and/or one or more existing on-link prefixes are deprecated. The reason for this is that such a significant change may indicate a configuration change at the server. However, a client MUST rate‑limit such exchange attempts to avoid flooding a server with requests when there are link issues (for example, only doing one of these at most every 30 seconds).
> 
> The above selection of an exchange to initiate depends on the client's current state:
> 1. If the client has any valid delegated prefixes obtained from the server, it sends Renew (as if the T1 time expired) as described in Section 18.2.4.
> 2. Else, if the client obtained address(es) from the server, it sends Confirm as described in Section 18.2.3.
> 3. Else, if only network information was obtained from the server, it sends Information-request as described in Section 18.2.6.
> 
> 
>>    If not associated with a detection of having moved to a new link, ...
>>
>> This looks ok because all conditions in 18.2.12 up to that point are effectively incorporating that the client's "may have moved to a new link" detection was triggered.
> 
> I've also integrate this previous-email comment I made into the text proposal. I find the new starting sentence more clear; but others may disagree here.
Thanks for the text. It looks good to me. Applied.

Thanks!

Tomek