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

[Michal Vasko <[e-mail]>]

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 <[e-mail]>
> *Date: *Friday, 4 October 2024 at 12:12
> *To: *[e-mail] <[e-mail]>
> *Cc: *[e-mail] 
> <[e-mail]>, [e-mail] 
> <[e-mail]>, [e-mail] <[e-mail]>
> *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
>