Hello, 
i've been selecteced as RTG-DIR reviewer for the following draft.

RTG-DIR Review
Document: draft-ietf-grow-nrtm-v4-08
Title: Network Routing Table Mirroring Protocol Version 4 (NRTMv4)
Review Date: 2026-02-27
Intended Status: Proposed Standard

This document defines NRTMv4, an HTTPS-based protocol for mirroring IRR databases using signed Update Notification Files, Snapshot Files, and Delta Files.
The protocol is well structured and represents a clear improvement over legacy mirroring mechanisms (e.g., FTP and NRTMv3). The use of HTTPS transport and signed notification files meaningfully improves integrity and deployability.
I believe the document is close to ready, but the issues below should be addressed (most can likely be handled with clarification text rather than protocol redesign).

Major Comments
- 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

In routing environments, unnecessary fallback to full snapshot reloads can significantly increase traffic and delay filter updates.I would reccomend to add normative (or at least strongly recommended) client recovery behavior like: Retry strategy with bounded exponential backoff, maximum retry duration before snapshot fallback, guidance for handling temporary publication inconsistency.

Minor comments:
The following points are suggestions for clarification and operational guidance; none rise to the level of blocking concerns:
- Delta continuity and recovery: Additional guidance on client retry behavior and snapshot fallback when contiguous delta versions are temporarily unavailable would improve implementability.
- Delta chain scaling: Operational recommendations on maximum delta chain length or snapshot frequency relative to churn would help large deployments.
- 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.
- CDN and caching behavior: More explicit guidance on HTTP cache-control and validation headers would reduce the risk of serving stale update notification files.
These are clarifications rather than protocol design issues.

Thanks
Daniele