Many thanks Sasha Be well, G/ ________________________________ From: Sasha Romijn <[email protected]> Sent: Wednesday, April 15, 2026 1:29 PM To: Gunter van de Velde (Nokia) <[email protected]> Cc: The IESG <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]> Subject: Re: Gunter Van de Velde's No Objection on draft-ietf-grow-nrtm-v4-09: (with COMMENT)
CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information. 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]
