You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Maybe this is OK, since the window is only a suggestion, but I noticed that this algorithm in section 4.2:
Select a uniform random time within the suggested window.
If the selected time is in the past, attempt renewal immediately.
Otherwise, if the client can schedule itself to attempt renewal at exactly the selected time, do so.
Otherwise, if the selected time is before the next time that the client would wake up normally, attempt renewal immediately.
Otherwise, sleep until the next normal wake time, re-check ARI, and return to Step 1.
can result in clients renewing before the renewal window.
Let's say the client wakes up once every 24 hours (that's very infrequent, but for the purposes of this discussion let's go with this). It wakes up 23 hours before the start of the renewal window, and 23.1 hours before the selected time (it happened to be toward the very beginning of the window). Step 2 is out because it's in the future. Let's say step 3 is out too, since it can't schedule itself. Step 4 then says to perform renewal immediately, which is still 23 hours before the renewal window even starts.
Is that acceptable? Or should the client wait until it's in the renewal window (but then miss the selected time, albeit just a little bit in this case)?
My code so far looks something like cutoff := cert.ari.SelectedTime.Add(-cfg.certCache.options.RenewCheckInterval). So, of course, if cert.ari.SelectedTime is near the beginning of the window, and cfg.certCache.options.RenewCheckInterval is any amount large, the resulting cutoff is likely to be before the start of the window.
You know I'm in favor of earlier renewals 🙂 , but I did want to seek clarification on this.
The text was updated successfully, but these errors were encountered:
Yes, the situation you describe is acceptable -- if it wasn't, I wouldn't have specified it.
Note that the algorithm is merely RECOMMENDED. If you believe you have a better algorithm, then implementing that is perfectly acceptable.
We could amend the algorithm to say "If the next time that the client would wake up normally is within the renewal window, do step 5", but that extra layer of complexity didn't seem worthwhile to me.
Maybe this is OK, since the window is only a suggestion, but I noticed that this algorithm in section 4.2:
can result in clients renewing before the renewal window.
Let's say the client wakes up once every 24 hours (that's very infrequent, but for the purposes of this discussion let's go with this). It wakes up 23 hours before the start of the renewal window, and 23.1 hours before the selected time (it happened to be toward the very beginning of the window). Step 2 is out because it's in the future. Let's say step 3 is out too, since it can't schedule itself. Step 4 then says to perform renewal immediately, which is still 23 hours before the renewal window even starts.
Is that acceptable? Or should the client wait until it's in the renewal window (but then miss the selected time, albeit just a little bit in this case)?
My code so far looks something like
cutoff := cert.ari.SelectedTime.Add(-cfg.certCache.options.RenewCheckInterval)
. So, of course, ifcert.ari.SelectedTime
is near the beginning of the window, andcfg.certCache.options.RenewCheckInterval
is any amount large, the resultingcutoff
is likely to be before the start of the window.You know I'm in favor of earlier renewals 🙂 , but I did want to seek clarification on this.
The text was updated successfully, but these errors were encountered: