From ebf19ca7608810000c71fa9b35b0142ba9deaa67 Mon Sep 17 00:00:00 2001 From: Paul Donald Date: Fri, 25 Apr 2025 02:18:49 +0200 Subject: [PATCH] doc: fix should word order --- doc/chrony.conf.adoc | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/doc/chrony.conf.adoc b/doc/chrony.conf.adoc index 3019eefe..d514eeb7 100644 --- a/doc/chrony.conf.adoc +++ b/doc/chrony.conf.adoc @@ -113,7 +113,7 @@ The MAC is generated as a function of a key specified in the key file, which is specified by the <> directive. + The *key* option specifies which key (with an ID in the range 1 through 2^32-1) -should *chronyd* use to authenticate requests sent to the server and verify its +*chronyd* should use to authenticate requests sent to the server and verify its responses. The server must have the same key for this number configured, otherwise no relationship between the computers will be possible. + @@ -1875,7 +1875,7 @@ ntsaeads 15 This list is used also by the <>. + Note the the NTS specification (RFC 8915) requires servers to support -AES-SIV-CMAC-256, i.e. 15 should be always included in the specified list. +AES-SIV-CMAC-256, i.e. 15 should always be included in the specified list. + The AES-128-GCM-SIV keys used by *chronyd* do not comply to RFC 8915 for compatibility with older *chrony* clients unless the use of compliant keys is @@ -2822,7 +2822,7 @@ To avoid calculating the offset with a less accurate transmit timestamp, *chronyd* can save the response for later processing and wait for the hardware transmit timestamp. There is no guarantee that the timestamp will be provided (NICs typically have a limited rate of transmit timestamping). This directive -configures how long should *chronyd* wait for the timestamp after receiving a +configures how long *chronyd* should wait for the timestamp after receiving a valid response from the server. If a second valid response is received from the server while waiting for the timestamp, they will be both processed immediately. -- 2.47.2