Skip to main content

Last Call Review of draft-ietf-netconf-transaction-id-06
review-ietf-netconf-transaction-id-06-yangdoctors-lc-vasko-2024-10-04-00

Request Review of draft-ietf-netconf-transaction-id
Requested revision No specific revision (document currently at 11)
Type IETF Last Call Review
Team YANG Doctors (yangdoctors)
Deadline 2024-10-16
Requested 2024-10-02
Requested by Per Andersson
Authors Jan Lindblad
I-D last updated 2026-04-10 (Latest revision 2025-10-07)
Completed reviews Yangdoctors IETF Last Call review of -06 by Michal Vaško (diff)
Opsdir IETF Last Call review of -07 by Bing Liu (diff)
Assignment Reviewer Michal Vaško
State Completed
Request IETF Last Call review on draft-ietf-netconf-transaction-id by YANG Doctors Assigned
Posted at https://mailarchive.ietf.org/arch/msg/yang-doctors/F-ftZftcC0sTff_u3QuGrTJozSQ
Reviewed revision 06 (document currently at 11)
Result Ready w/nits
Completed 2024-10-04
review-ietf-netconf-transaction-id-06-yangdoctors-lc-vasko-2024-10-04-00
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.

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. 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?

Regards,
Michal Vasko