Hi Sasha, Thanks for your response and for posting the update. Please check inline below for follow-up items. I'll clear my DISCUSS position shortly.
Btw, one potential issue has crept into section 4.3.2? s/ Mirror servers should not generate new Snapshot Files more than once per hour/ Mirror servers SHOULD NOT generate new Snapshot Files more than once per hour On Wed, Apr 15, 2026 at 5:20 PM Sasha Romijn <[email protected]> wrote: > 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. KT> Thanks. > > > > 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. > KT> Thanks. I understand it now by looking back and forth through the text. Please consider this closed. > > > 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. > KT> Ack > > > <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. > KT> Sure. We can consider this closed. > > > 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. > KT> Thanks > > > 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. > KT> Thanks. That is helpful indeed. > > > 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. > KT> Correct. I don't remember finding text stating that the server can or should handle such clients in this manner. If it is covered, please ignore and if not, please consider adding it. Thanks, Ketan > > Sasha > >
_______________________________________________ GROW mailing list -- [email protected] To unsubscribe send an email to [email protected]
