IETF Last Call Review of draft-ietf-grow-nrtm-v4-08
review-ietf-grow-nrtm-v4-08-rtgdir-lc-ceccarelli-2026-02-28-00

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