Hello Ketan, Thanks for the review of our draft. We made several changes to the draft based on your comments in https://github.com/mxsasha/nrtmv4/commit/3a47224dcc942f214761af96ca8fff9a84adbf02
Further responses inline: On 14 Apr 2026, at 12:45, Ketan Talaulikar via Datatracker <[email protected]> wrote > <discuss-1> Section 4.3.2 says "The mirror server SHOULD continue to produce > Delta Files during this window, which means that the server may publish a > Snapshot File with a version number older than the most recent Delta File at > the time of publication." > > The scenario being described before that text is definitely possible and > defining the behavior is helpful. I am concerned why it is SHOULD and not a > MUST to provide deterministic behavior to clients. We agree, this is now a MUST. > Also, I would have expected > that an incremental version number at the start of the snapshot process is > "reserved" for use with that snapshot and further increments be done for the > delta files such that the delta files version numbers are larger than the > snapshot. After the initial snapshot, the server always generates both a snapshot and a delta for the same version. The concept is that a client may arrive at version 10 either by downloading snapshot 10, or having previously downloaded snapshot 8, then applied deltas 9 and 10. The same version for a client always presents the same data, regardless of the path. Therefore, snapshots do not have a reserved number. > Alternately, to keep things simple, why not just suspend the delta file > generation while snapshot is in progress, and then do a "one larger catch-up > Delta file" as indicated in section 4.3.1 ? The intention is that clients keep receiving up to date data, even while the server generates snapshots. Otherwise, mirroring would be frozen regularly, depending on the size of the database and how long it takes to generate the snapshot. > <discuss-2> Section 4.3.3 does not talk about the version number and > incrementing/update that the server needs to do for the Update Notification > file. The use of this version number by the client is specified in Sec 5.4 > though and it would be good to specify the server side aspects in 4.3.3? This > section is very thin and seems to lack the details on how the server > generates/updates and publishes the Update Notification file as compared to > the > snapshot and delta files. We added a forward reference from 4.3.3 to section 6, which details the specifics of version numbers in the Update Notification File as part of its format. Does that address your concern sufficiently? We also wanted to avoid duplication of information. > 1) In section 2, "NRTMv3 serials can also contain gaps, NRTMv4 versions may > not." ... shouldn't the "may not" be "do not" ? Yes. This was adopted. > 2) Section 4.3.1, "The URL where the Delta File is published MUST contain the > session ID and version number to allow it to be indefinitely cached." Is this > caching done by the Mirror Server or someone else? If it is done by the Mirror > Server, then this seems to contradicts with section 9.5 "After publishing a > new > Update Notification File, and absent local policy, a mirror server SHOULD > remove any Snapshot and Delta Files that are no longer referenced." and also > much of the "Cache Concerns" sections and other text in section 6, 7 and 8 ... > or am I missing something? There is also a similar "indefinitely cached" for > snapshot in section 4.3.2. The caching referred here relates more to intermediaries or frontend webservers. This way, the standard guarantees content at a certain URL (i.e. the content of a particular Snapshot/Delta) will never change, no cache expiry mechanism is needed in them, other than eventual eviction to save caching space. We've updated this in the document to be clearer. > 3) Section 5.2, "Mirror clients MUST NOT check more than once per minute." - > what does the server do if this happens? There is no requirement for the server to verify this, but, if client behaviour becomes problematic, this requirement could be used to justify servers blocking of clients, or to require changes from client implementations. As they would clearly be in violation of the specification. Sasha _______________________________________________ GROW mailing list -- [email protected] To unsubscribe send an email to [email protected]
