Sasha,
Thanks for addressing these issues.
Paul
On 3/17/26 1:30 PM, Sasha Romijn wrote:
Hello,
Thank you for this review. Our responses inline:
On 25 Feb 2026, at 18:17, Paul Kyzivat <[email protected]> wrote:
1) NIT: Undefined term:
Section 1 (Introduction) uses the term "RIR". This appears nowhere else in the
document. Please provide a definition/expansion for this term.
Agree, fixed.
2) NIT: Unspecified rationale for specific time intervals:
There are frequency rules tied to one minute, one hour, and 24 hour intervals.
I gather the intent is to balance the need for timely data against the load on
clients and servers to keep the data up-to-date. It seems to me that the load
generated by these will vary based on number of clients. And the
appropriateness of these may vary depending on the type of data. It would be
helpful to have some explanation for why these specific values have been chosen.
We picked the intervals to fit common practice by IRR operators, and took some
inspiration from RRDP:
- 1 minute for Delta/Update Notification File publication: we felt this was a
decent balance: increased frequency would increase load with limited benefit;
coarser granularity would delay propagation of route filter changes that
operators depend on.
- 1-24h period for Snapshot generation: snapshots contain the full database and
can be large. Generating them too frequently would be wasteful given that
Delta-based updates are the normal path, generating them too rarely would
create long Delta chains for new clients. The range gives operators flexibility
to trade off Snapshot production load against Delta chain length for their
specific deployment, while placing bounds in either direction.
We did add more guidance for operators regarding Snapshot generation in
https://github.com/mxsasha/nrtmv4/pull/105/changes as this also came up in the
RTGDIR review.
3) NIT: Under-specified error handling:
There are many places that identify error conditions and state that when these
occur the file MUST be rejected. But I find no explanation of what is to be
done when a file is rejected in this way. I presume there must be some recovery
action.
This was quite ambiguous, and noted by multiple reviewers. This is now
clarified as part of https://github.com/mxsasha/nrtmv4/pull/105/changes
4) NIT:
In the example payload of an Update Notification File in section 6.3, the snapshot
is version 3. and there are deltas with versions 2,3, and 4. Why are there are
deltas with versions 2 & 3? Isn't version 4 the first delta version applicable
to this snapshot? I presume there is a reason. It would be helpful if this was
explained.
I can see how that is not clear. We added an explanation in
https://github.com/mxsasha/nrtmv4/pull/109/changes
5) NIT: The future evolution of this protocol:
The IANA Considerations section makes a provocative statement:
"NRTMv4 is expected to be the final revision of the protocol family used for IRR
database replication. Solution requirements that arise in the future are likely best
solved using either RPKI [RFC6480] or RDAP [RFC9082]. From that perspective, the document
does not define any IANA registry for protocol maintenance."
We've simplified this section:
https://github.com/mxsasha/nrtmv4/pull/112/changes
Sasha
_______________________________________________
GROW mailing list -- [email protected]
To unsubscribe send an email to [email protected]
