Re: WGLC for draft-ietf-dhc-rfc8415bis / clarification of significant prefix change
Tomek Mrugalski <[email protected]>
| Newsgroups | gmane.ietf.dhc |
|---|---|
| Message-ID | <[email protected]> |
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 _______________________________________________ dhcwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/dhcwg