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