[Ntp] Gunter Van de Velde's No Objection on draft-ietf-ntp-interleaved-modes-07: (with COMMENT)

[Gunter Van de Velde via Datatracker <[e-mail]>]

Gunter Van de Velde has entered the following ballot position for
draft-ietf-ntp-interleaved-modes-07: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ntp-interleaved-modes/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

# Gunter Van de Velde, RTG AD, comments for draft-ietf-ntp-interleaved-modes-07

## Many thanks for writing this document. The text was good to read from the
perspective of not being very NTP technology aware

## The comments below are mostly of cosmetic nature and suggest alternate
textblobs. Use them as you find beneficial.

#GENERIC COMMENTS
#================
## Document has some unusual idnits warnings

#DETAILED COMMENTS
#=================
##classified as [minor] and [major]

11      Abstract
12
13         This document extends the specification of Network Time Protocol
14         (NTP) version 4 in RFC 5905 with special modes called the NTP
15         interleaved modes, that enable NTP servers to provide their clients
16         and peers with more accurate transmit timestamps that are available
17         only after transmitting NTP packets.  More specifically, this
18         document describes three modes: interleaved client/server,
19         interleaved symmetric, and interleaved broadcast.

[minor]
While the abstract is fine and correct, it may be made more abstract for a
reader not overly familiar with NTP. Proposed alternative abstract textblob.
Use or ignore at desire of the document authors/editors

"
This document specifies interleaved modes for the Network Time Protocol (NTP),
which improve the accuracy of NTP time synchronization by reducing the impact
of network delays. The interleaved modes separate the transmission of the
timestamps from the regular NTP message exchange, allowing for more precise
measurement of round-trip times and better compensation for delays. These
enhancements are intended to improve timekeeping in environments where high
precision is critical. This document updates RFC 5905 by defining these new
operational modes. "

197        A server which supports the interleaved mode needs to save pairs of
198        local receive and transmit timestamps.  The server SHOULD discard old
199        timestamps to limit the amount of memory needed to support clients
200        using the interleaved mode.  The server MAY separate the timestamps

[minor]
What is considered 'old timestamp'? is there a recommended upper boundary or is
that something the operator needs to decide adhoc?

356        A check for a non-zero origin timestamp works with SNTP clients that
357        always set the timestamp to zero and clients that implement NTP data
358        minimization [I-D.ietf-ntp-data-minimization].  From the server's

[minor]
first time usage of SNTP does not have a refence to RFC5905 (which obsoleted
RFC4330) or expands on the acronym "Simple Network Time Protocol (SNTP) Version
4"