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]
