Gunter Van de Velde has entered the following ballot position for draft-ietf-grow-nrtm-v4-09: No Objection
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-grow-nrtm-v4/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- # Gunter Van de Velde, RTG AD, comments for draft-ietf-grow-nrtm-v4-09 # The line numbers used are rendered from IETF idnits tool: https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-grow-nrtm-v4-09.txt # Thank you for this work and for the nice write-up. Most of my comments are observations and clarifications as this specific technology space is new, and interresting, to me. # thanks to Daniele Ceccarelli for the RTGDIR review # DISCUSS # ======== # Detailed Review # =============== 17 This document specifies a one-way synchronization protocol for 18 Internet Routing Registry (IRR) records, called Near Real Time 19 Mirroring version 4 (NRTMv4), in which files are distributed over 20 HTTPS. The protocol allows instances of IRR database servers to 21 mirror IRR records, specified in the Routing Policy Specification 22 Language (RPSL), between each other. 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? 150 In NRTMv4, a mirror server is an instance of IRR Database software 151 that has a database of IRR objects and publishes them to allow 152 mirroring by others. These objects can be retrieved by mirror 153 clients, which then load them into their local storage. The IRR 154 Database has a version, which the mirror server starts at 1, and 155 increments every time it publishes a set of changes. GV> Can you clarify what 'publishes' means in this context? does it mean to make it available for retrieval by using https? GV> I assume that the version number is locally significant? is it a value that is "ephemeral" or is version number retained during reboots? 199 object in large files can be parsed independently. Files MAY be 200 compressed with GZIP [RFC1952]. GV> GZIP seems to be of reasonable age. have more modern compression schemes like Brotli (RFC 7932) or Zstandard (RFC 8878) been considered? 202 Mirror clients initially retrieve the small Update Notification File 203 and a Snapshot File, from which they initialize their local copy of 204 the Database. After that, mirror clients only retrieve the Update 205 Notification File periodically, typically every minute, to determine 206 whether there are any changes, and then retrieve only the relevant 207 Delta Files, if any. This minimizes data transfer. Deltas have 208 sequential versions. 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. 312 Note that a publication, and its associated session_ids and versions, 313 always relates to a single specific IRR Database, even if multiple 314 databases are published from one instance. For example, a mirror 315 server publishing NRTMv4 for RIPE and RIPE-NONAUTH, will generate two 316 Update Notification Files, referring to two Snapshot Files, and two 317 sets of Delta Files each with contiguous version numbers - all GV> Maybe add reference to RIPE and RIPE-NONAUTH. It is first i hear the term RIPE-NONAUTH. 322 4.3. Publishing Updates 324 324 After creating the initialization files, the mirror server processes 325 updates by publishing Delta Files and, periodically, a new Snapshot 326 File. GV> I get the impression that the ternm "publishing" has two specific meanings in this document. (1) the procedure where a database of IRR objects is made available through (Update Notif File, Snapshot file and Delta file), and (2) the using the same term in "publishing Delta files" or "A mirror server MUST publish a Delta File" where publishing/publish is used for single operation to make a single file available for retrieval by clients. This looks slightly confusing terminology. Thanks for this write-up. Gunter Van de Velde RTG Area Director _______________________________________________ GROW mailing list -- [email protected] To unsubscribe send an email to [email protected]
