[Last-Call] Re: Yangdoctors last call review of draft-ietf-netconf-transaction-id-06

[Michal Vasko <mvasko=40cesnet.cz@xxxxxxxxxxxxxx>]

Hi Jan,

regarding the clocks, yes, I suppose I have some practical experience with this and I think I was even facing similar issues. At some point we have decided to use real timestamps for data versioning. Long story short, even ignoring the problem of backward time jumps, we ended up switching to a simple iterator because there were too many issues and corner cases with real time. Actually, I can illustrate them on a paragraph from the draft

It is RECOMMENDED that server implementors choose the number of digits of precision used for the fractional second timestamps high enough so that there is no risk that multiple transactions on the server would get the same timestamp.

The risk of 2 timestamps actually being the same despite data having changed is always there. Because there is always certain clock precision, no matter how many precision digits you decide to use, and, to make matters worse, on Linux the real-time timestamp is being cached from my experience, which lessens the precision even more. I mean, our use-case was a local app so this happening over NETCONF/RESTCONF seems pretty much impossible, but it cannot be completely ruled out.

So, my question would be, what exactly is the advantage of using last-modified instead of txid? I see that the document also mentions RESTCONF, which I have no experience with, but I would generally suggest using only txid or accepting all the problems of real-time timestamps and fully accepting them with just warnings describing the issues that may arise.

Regards,
Michal

On 7. 10. 2024 15:30, Jan Lindblad (jlindbla) wrote:

Thank you for your review, Michal!

Find comments below marked [janl].

 

From: Michal Vaško via Datatracker <noreply@xxxxxxxx>
Date: Friday, 4 October 2024 at 12:12
To: yang-doctors@xxxxxxxx <yang-doctors@xxxxxxxx>
Cc: draft-ietf-netconf-transaction-id.all@xxxxxxxx <draft-ietf-netconf-transaction-id.all@xxxxxxxx>, last-call@xxxxxxxx <last-call@xxxxxxxx>, netconf@xxxxxxxx <netconf@xxxxxxxx>
Subject: Yangdoctors last call review of draft-ietf-netconf-transaction-id-06

Reviewer: Michal Vaško
Review result: Ready with Nits

This is my YANG doctor review of draft-ietf-netconf-transaction-id.

As far as the YANG modules are concerned, they are fairly short and
straightforward. Except for outdated revisions, I have noticed no issues.

[janl] Very good.

I have also quickly read through the whole document and managed to understand
the main idea of the document, also thanks to the numerous examples, so that is
appreciated. I only have 2 comments. In Section 3.9. there is "The
<copy-config>` operation...", a stray ` should be removed.

[janl] Ah, thanks. Markdown issue fixed.

Also, in Section
4.2. there is a text about how the timestamp value should be generated. In
short and using POSIX clocks, it is RECOMMENDED to be close to CLOCK_REALTIME
but MUST have no jumps backward just like CLOCK_MONOTONIC. So what exactly is
an implementation supposed to do, maintain its own clock that satisfies both
conditions? Some more guidance would be useful. Even if going with something
like taking CLOCK_REALTIME on boot and manually adding CLOCK_MONOTONIC to it,
after some time jumps you will end up with a different time than the system
CLOCK_REALTIME, so the actual real time, is this really desired and acceptable?

[janl] I see what you are saying. You obviously know a lot more about clocks than I do. What would you recommend that we write? It needs to be monotonic for the algorithm to work, so should we say CLOCK_MONOTONIC (and skip all that about close to real time) with some POSIX reference, or is it enough to say that the time stamps need to be strictly increasing?

Best Regards,
/jan

<<attachment: smime.p7s>>

-- 
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx