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
