[netconf] Yangdoctors last call review of draft-ietf-netconf-transaction-id-06
Michal Vaško via Datatracker <noreply@ietf.org> Fri, 04 October 2024 10:12 UTC
Return-Path: <noreply@ietf.org>
X-Original-To: netconf@ietf.org
Delivered-To: netconf@ietfa.amsl.com
Received: from [10.244.8.145] (unknown [104.131.183.230]) by ietfa.amsl.com (Postfix) with ESMTP id 961EFC15108B; Fri, 4 Oct 2024 03:12:23 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Michal Vaško via Datatracker <noreply@ietf.org>
To: yang-doctors@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 12.25.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <172803674311.189.3889357308407884091@dt-datatracker-cb674fff7-jr9km>
Date: Fri, 04 Oct 2024 03:12:23 -0700
Message-ID-Hash: HY4XDB3D4ICJ3U4BF5QTG5SNKLEGHDHP
X-Message-ID-Hash: HY4XDB3D4ICJ3U4BF5QTG5SNKLEGHDHP
X-MailFrom: noreply@ietf.org
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-netconf.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: draft-ietf-netconf-transaction-id.all@ietf.org, last-call@ietf.org, netconf@ietf.org
X-Mailman-Version: 3.3.9rc5
Reply-To: Michal Vaško <mvasko@cesnet.cz>
Subject: [netconf] Yangdoctors last call review of draft-ietf-netconf-transaction-id-06
List-Id: NETCONF WG list <netconf.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/wU_yX4Ui9KWUKvoYQ3fZJJ8ntrk>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Owner: <mailto:netconf-owner@ietf.org>
List-Post: <mailto:netconf@ietf.org>
List-Subscribe: <mailto:netconf-join@ietf.org>
List-Unsubscribe: <mailto:netconf-leave@ietf.org>
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. 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
- [netconf] Yangdoctors last call review of draft-i… Michal Vaško via Datatracker
- [netconf] Re: Yangdoctors last call review of dra… Jan Lindblad (jlindbla)
- [netconf] Re: Yangdoctors last call review of dra… Michal Vasko