Hello Gunter,
Thank you for the review.
We updated the document with clarifications based on your comments in
https://github.com/mxsasha/nrtmv4/commit/c4a6d72e100eda217b58668eebcf2fa995e0b797
Specific responses inline:
On 14 Apr 2026, at 12:07, Gunter Van de Velde via Datatracker
<[email protected]> wrote:
> GV> This draft documents NRTMv4. It took me a while reading the text to
> realize
> that there was prior art with NRTMv3. Maybe few words can be mentioned. also
> where was NRTMv1 described? Was that https://www.rfc-editor.org/rfc/rfc2650?
> Did ever anything happen with NRTMv2? Maybe mentione a phraze that there was
> prior NRTM art in existance and the novelty that this specific version
> introduces?
The history of NRTM is somewhat fuzzy. NRTMv3 is a page in RIPE NCC's website,
that leaves many open questions. NRTMv1 appears to be an interpretation of
NRTMv3 with certain stripped fields. NRTMv2 does not exist to my knowledge.
None of them are defined in an RFC.
> GV> Can you clarify what 'publishes' means in this context? does it mean to
> make it available for retrieval by using https?
That is what it means. We made this clearer in the document.
> GV> I assume that the version number is locally significant? is it a value
> that
> is "ephemeral" or is version number retained during reboots?
The version number persists during the session, where a session could last
years. It resets only a new session is started, with a new session_id.
> GV> GZIP seems to be of reasonable age. have more modern compression schemes
> like Brotli (RFC 7932) or Zstandard (RFC 8878) been considered?
For this, I'll refer to Job's reply to Mike Bishop:
https://mailarchive.ietf.org/arch/msg/grow/SMVuSKCL8sxZBD9W5dFLuPrQ8Xs/
> GV> The above describes a pull mechanism from client to the mirror server.
> That
> sounds rather procedure heavy. Has a procedure similar to netconf
> notifications
> been considered, where a client subscribes at the server to updates and gets
> each update instantaniously through triggered notifications? It seems less
> procedure heavy and easier for the mirror to simply send updates to subscribed
> clients then for each client to go through the request and response
> periodically. Maybe i misunderstood the summary in this paragraph though.
Your description is correct. NRTMv3 used a subscription mechanism, but
operational experience found it hard to scale sufficiently. The idea for NRTMv4
is to allow scaling over standard HTTPS infrastructure, or even CDNs. This
separates the load from the IRR server itself, and moves it to a more suited
platform. The Update Notification File is a small enough index with good
caching options.
> GV> Maybe add reference to RIPE and RIPE-NONAUTH. It is first i hear the term
> RIPE-NONAUTH.
We've made these examples more generic.
Sasha
_______________________________________________
GROW mailing list -- [email protected]
To unsubscribe send an email to [email protected]
