Maintenance Windows for Offline Devices: Decide What Happens When the Window Is Missed

A device that reconnects after a maintenance window should follow an explicit late-execution policy. It may wait for the next approved occurrence, request renewed authorization, or run under a previously approved grace rule. It should not interpret “an update was once assigned” as permission to install at any later time.

This guide defines an original campaign-window contract. It uses RFC 9019’s separation of download and installation timing and RFC 9124’s optional manifest-expiration concept. It does not configure a scheduler or define civil-time conversion rules. No device, clock or campaign was changed.

1. State what the window permits

A maintenance window can mean permission to start downloading, start writing an inactive slot, reboot, or complete a service interruption. Those meanings produce different admission decisions. Choose the protected milestone before choosing timestamps.

RFC 9019 section 3 allows downloaded content to await an installation trigger or another timing decision. Use that separation deliberately: storing an approved artifact before the window need not authorize activation outside it.

Window contract	Admission test	Boundary concern
Start-only permission.	The defined start milestone occurs within the interval.	Completion may occur later only if explicitly allowed.
Service interruption must fit.	The qualified interruption allowance fits before the end.	Download completion alone says nothing about reboot readiness.
Separate install and reboot windows.	Each milestone has its own current authorization.	Prepared content must not trigger an unscheduled reboot.

Do not describe all three as “install between 02:00 and 03:00.” The implementation and operator need the same milestone definition.

2. Store an occurrence, not an ambiguous local label

Resolve the approved schedule into an unambiguous start and end instant for a particular occurrence. Keep the operator’s timezone and scheduling-rule revision as audit context, but let the device compare the resolved interval rather than inventing its own interpretation of a repeated local hour.

The record should bind campaign identity, artifact identity, occurrence identity, policy revision, permitted milestone, start, end, expiry and late-execution rule. A new occurrence has a new identity even if its displayed local hour is the same.

Use an explicit interval convention. For example, the original policy below uses a start-inclusive, end-exclusive interval. Exactly at the end is too late for a new start. This is an application choice, not a required RFC encoding.

3. Choose a late-reconnect policy before deployment

Approved policy	After the window was missed	Evidence required
Skip this occurrence.	Remain pending for another explicitly applicable occurrence.	Missed occurrence is recorded, not reported as installation failure.
Renew authorization.	Contact the campaign authority and await a new decision.	Renewal names the current artifact and destination scope.
Bounded grace period.	Evaluate a separately defined late interval and conditions.	The grace rule was approved in advance and remains current.
Operator-controlled service.	Expose a hold requiring the established service process.	Actual authorization is obtained before proceeding.

Do not create a grace period by adding the offline duration to the original end time. That converts a missed schedule into an unlimited rolling permission. Likewise, repeated reconnects must not create fresh occurrences or restart a grace interval.

If the product supports offline authorization, define how long it remains usable and which revocation limitations the operator accepts. A disconnected device cannot learn an immediate server-side cancellation. Report that limitation rather than assuming a cached decision is always current.

4. Keep window expiry separate from artifact expiry

RFC 9124 section 3.7 describes an optional expiration time for a manifest and relates it to secure time. That is different from a maintenance window chosen by the operator.

A new maintenance occurrence does not automatically make an expired manifest acceptable. Conversely, a still-valid manifest does not grant permission to interrupt service outside the operator’s window. Evaluate both contracts, along with compatibility, trust and any supersession policy.

Renew the element that actually expired through its authorized process. If only the scheduling permission changed, preserve the approved artifact identity. If the authority supplies new update metadata, validate it normally rather than mutating a signed object locally.

5. Treat clock uncertainty as an admission input

Record the clock source, its freshness and the maximum uncertainty accepted by the product. A plausible calendar display is insufficient when a device has spent months offline or lost its clock state.

For a conservative completion-window policy, suppose current time is known only to lie between Tlow and Thigh. Admit a stage only when Tlow is at or after the window start and Thigh plus its qualified duration allowance is before the window end. The strict end comparison follows this example’s end-exclusive rule.

This is a proposed engineering gate, not a hard real-time guarantee. The duration allowance must include the required processing, reboot and recovery margins for the chosen milestone. If the product cannot bound the relevant interval, it cannot honestly promise completion inside the window.

If time is unavailable or the uncertainty overlaps a boundary, hold or request renewed timing evidence. Do not move the clock backward, ignore expiry or guess that an offline device is still inside its old window.

6. Recheck at the last qualified admission point

A device can start downloading early, then reach installation after the window has closed. Re-evaluate the relevant permission immediately before the protected stage. Include time spent waiting for power readiness, locks or user activity to stop.

Once a stage crosses its qualified noninterruptible boundary, window expiry is not an instruction to cut power or terminate a flash write. The product’s approved in-progress completion or recovery policy governs that state. Choose that behavior before rollout.

1. Reconnect before, exactly at and after each boundary.
2. Finish download just before the window closes, with insufficient installation allowance.
3. Reboot with a cached occurrence that has already been consumed.
4. Lose clock validity while waiting for admission.
5. Receive a newer campaign decision after an older timer was scheduled.
6. Cross the end boundary during an admitted noninterruptible stage.

These are proposed fixture cases. Require a distinct outcome for missed, expired, superseded, clock-unresolved and already-in-progress states. A stale timer must not execute an occurrence merely because it was once queued.

Hypothetical late factory reconnect

A gateway misses its approved service-interruption interval while the factory network is unavailable. It reconnects during production hours with a valid downloaded image. Under a renew-authorization policy, it reports the missed occurrence and waits; it does not reboot immediately.

The operator can approve a new occurrence for the same verified artifact. Preserve both records so the delay is explainable without labeling the earlier absence as a failed installation or claiming that cached content carried unlimited execution permission.