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

[Esko Dijk <[e-mail]>]

Hello Tomek,

> > items 2 (clarify when to send confirm, renew or inf-request)
> > ...
> > Do you have any text in mind here?
> Not yet - but I can make a proposal next week?

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
Esko