Hello, Thank you for the review. Responses inline:
On 28 Feb 2026, at 15:40, Daniele Ceccarelli via Datatracker <[email protected]> wrote > - Delta Continuity and Recovery Semantics: The document requires strict > contiguous delta version processing and mandates client rejection when gaps > are > detected. However, it does not clearly define the following 3 items: - > Expected > client retry behavior when a delta version is temporarily unavailable - > Backoff > recommendations - When to fall back to snapshot reinitializationh - Wether > transient gaps (e.g., CDN lag) are expected operationally Yes, I can see the issue. We wouldn't want excessive load for an occasional transient failure. We've addressed this by adding more detail on client behaviour around this in: https://github.com/mxsasha/nrtmv4/pull/105/changes (along with other error handling improvements noted by other reviews) > - Delta chain scaling: Operational recommendations on maximum > delta chain length or snapshot frequency relative to churn would help large > deployments We added a recommendation for this in the same PR. Due to Delta expiry after 24 hours, the maximum is fixed at 1440 (if every minute of the 24 hours had at least one change). In servers with a high rate of change, this is still significant, so those are recommended to generate snapshots more often in the same diff. > - Staleness thresholds: The 24-hour staleness check may be > sufficient for safety, but routing automation environments typically require > much shorter freshness expectations. A brief operational note could clarify > this. The purpose of the staleness check isn't to assure freshness, but rather to know if the repository is still active. Some registries have a low rate of change, and then this staleness can be used to distinguish "there is no software running that still publishes to this URL" from "there have been no changes in a long time". This has been an issue with NRTMv3. > - CDN and caching behavior: More explicit guidance on HTTP cache-control > and validation headers would reduce the risk of serving stale update > notification files. I agree. This has been added in the same PR. Thanks, Sasha _______________________________________________ GROW mailing list -- [email protected] To unsubscribe send an email to [email protected]
