Authors,
While reviewing this document during AUTH48, please resolve (as necessary)
the following questions, which are also in the XML file.
1) <!-- [rfced] Section 1: We see that the text says "at least four
options", but only four options are listed. Should other options be
included in the list, or should the text be rephrased?
Original:
There are at least four options where a timestamp of an NTP packet
may be captured with a software NTP implementation running on a
general-purpose operating system:
Possibly:
Four options where a timestamp of an NTP packet may be captured with
a software NTP implementation running on a general-purpose operating
system are as follows: -->
2) <!-- [rfced] Figures 1, 2, and 3: It appears that "Org" might refer
to the origin timestamp as used throughout the text. We ask because
"Org" often refers to an organization.
If "Org" means "origin timestamp", may we update as suggested?
Original:
Org | 0 | | t1~| | t2 | | t4 | | t6 | | t5 |
...
Org | 0 | | t1~| | t2 | | t3~| | t4 | | t3 | | t3 | |t10 |
...
Org | 0 | | t1 | | t3 | | t5 |
Suggested:
Origin | 0 | | t1~| | t2 | | t4 | | t6 | | t5 |
...
Origin | 0 | | t1~| | t2 | | t3~| | t4 | | t3 | | t3 | |t10 |
...
Origin | 0 | | t1 | | t3 | | t5 | -->
3) <!-- [rfced] Section 3: There appear to be some singular-vs.-plural
issues in this sentence. If the suggested text is not correct,
please clarify.
Original:
In order to prevent the peer from matching the transmit timestamp
with an incorrect packet when the peers' transmissions do not
alternate (e.g. they use different polling intervals) and a previous
packet was lost, the use of the interleaved mode in symmetric
associations requires additional restrictions.
Suggested:
In order to prevent a peer from matching transmit timestamps
with incorrect packets when its transmissions do not alternate
(e.g., different polling intervals are used) and one or more
previous packets were lost, the use of the interleaved mode in
symmetric associations requires additional restrictions. -->
4) <!-- [rfced] Section 3: As it appears that "since" in this sentence
indicates some period of time rather than meaning "because", we
modified the wording accordingly. If this is incorrect, please
clarify the meaning.
Original:
2. The peer A did not send a packet to the peer B since it received
the last valid packet from the peer B.
Currently:
2. Peer A did not send a packet to Peer B since the time that it
received the last valid packet from Peer B. -->
5) <!-- [rfced] Section 3: We found "The first packets ... are" in the
first sentence and "The second and third packet ... is" in the next
sentence confusing. It also appears that "the following packets" in
the third sentence means "subsequent packets", as opposed to
referring specifically to the packets shown in Figure 2.
Please review the updated text. If anything is incorrect, please
clarify the use of singular versus plural in these sentences.
Original:
The first
packets sent by the peers are in the basic mode. The second and
third packet sent by the peer A is in the interleaved mode. The
second packet sent by the peer B is in the interleaved mode, but the
following packets sent by the peer B are in the basic mode, because
multiple responses are sent per request.
Currently:
The first packet sent by
each peer is in the basic mode. The second and third packets sent by
Peer A are in the interleaved mode. The second packet sent by Peer B
is in the interleaved mode, but subsequent packets sent by Peer B are
in the basic mode, because multiple responses are sent for each
request. -->
6) <!-- [rfced] Section 3: Because we see that the two sets of
timestamps are discussed in Section 2, for ease of the reader we
changed "the client/server section" to "Section 2". If this is
incorrect, please clarify what "the client/server section" refers to.
Original:
The peers can compute the offset and delay using one of the two sets
of timestamps specified in the client/server section.
Currently:
The peers can compute the offset and delay using one of the two sets
of timestamps specified in Section 2. -->
7) <!-- [rfced] Section 5: We could not follow "responses responded"
in this sentence and so cannot determine what were received at the
same time (i.e., the requests or the responses?). Perhaps some words
are missing? Please clarify the text.
Original:
As
the two requests to which the responses responded were received at
the same time (according to the server's clock), the two
transmissions would be expected to be close to each other and the
difference between them would be comparable to the error a basic
response normally has in its transmit timestamp. -->
8) <!-- [rfced] Section 6: Should "basic modes" here be "basic mode"?
We ask because we see the singular "basic mode" used everywhere else
in this document. If not, does "basic modes" refer specifically to
the modes discussed in RFC 5905?
Original:
Security issues that apply to the basic modes apply also to the
interleaved modes. They are described in The Security of NTP's
Datagram Protocol [SECNTP].
Possibly (if "basic modes" refers specifically to RFC 5905):
Security issues that apply to the basic modes discussed in
RFC 5905 [RFC5905] also apply to the interleaved modes. These
issues are described in "The Security of NTP's Datagram Protocol"
[SECNTP]. -->
9) <!-- [rfced] Section 6: Is a precision of 32 always used (in which
case "i.e.," is correct), or is "32" an example setting (in which
case "e.g.," would be correct)?
Original:
Clients using the interleaved mode SHOULD randomize all bits of
receive and transmit timestamps in their requests (i.e. use a
precision of 32) to make it more difficult for off-path attackers to
guess the origin timestamp in the server response. -->
10) <!-- [rfced] Acknowledgements: Are two modes listed here (basic
symmetric and client/server) or three modes? In other words, should
a comma be placed after "basic" to indicate the basic mode, or does
"basic symmetric" refer to the symmetric mode discussed in RFC 5905
(in which case perhaps RFC 5905 should be cited here)? Also, does
"similarly" refer to a mode (in which case it should be "similar")
or to "specified"?
Original:
The client/server mode is
specified as a new mode compatible with the symmetric mode, similarly
to the basic symmetric and client/server modes.
Possibly (guessing two modes and "similar"):
The client/server mode is
specified as a new mode compatible with the symmetric mode, similar
to the compatibility of the basic symmetric and client/server modes
as discussed in RFC 5905 [RFC5905]. -->
11) <!-- [rfced] Please review the "Inclusive Language" portion of the
online Style Guide at
<https://www.rfc-editor.org/styleguide/part2/#inclusive_language>,
and let us know if any changes are needed. Updates of this nature
typically result in more precise language, which is helpful for
readers.
Note that our script did not flag any words in particular, but this
should still be reviewed as a best practice. -->
12) <!-- [rfced] The following term appears to be used inconsistently in
this document. Please let us know which form is preferred.
interleaved broadcast mode (3 instances in text) /
broadcast interleaved mode (1 instance in Section 1) -->
13) <!--[rfced] We see the following in the shepherd writeup
(https://datatracker.ietf.org/doc/draft-ietf-ntp-interleaved-modes/shepherdwriteup/).
It's not clear to us what "next stage of publication" refers to. Please
confirm
that the issues have been addressed.
(11) Identify any ID nits the Document Shepherd has found in this document.
[...]
ID nits was run on 11 Feb 2021. The results at that time were:
Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (-).
These are minor issues that will be addressed during the next stage of
publication including the update of an outdated informative reference.
The idnits output for draft-ietf-ntp-interleaved-modes-08.txt currently
includes the following (using https://author-tools.ietf.org/idnits):
"The document seems to lack a disclaimer for pre-RFC5378 work, but may
have content which was first submitted before 10 November 2008. If you
have contacted all the original authors and they are all willing to grant
the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
this comment. If not, you may need to add the pre-RFC5378 disclaimer.
(See the Legal Provisions document at
https://trustee.ietf.org/license-info for more information.)"
-->
Thank you.
RFC Editor/lb/ar
On Apr 11, 2025, rfc-edi...@rfc-editor.org wrote:
*****IMPORTANT*****
Updated 2025/04/11
RFC Author(s):
--------------
Instructions for Completing AUTH48
Your document has now entered AUTH48. Once it has been reviewed and
approved by you and all coauthors, it will be published as an RFC.
If an author is no longer available, there are several remedies
available as listed in the FAQ (https://www.rfc-editor.org/faq/).
You and you coauthors are responsible for engaging other parties
(e.g., Contributors or Working Group) as necessary before providing
your approval.
Planning your review
---------------------
Please review the following aspects of your document:
* RFC Editor questions
Please review and resolve any questions raised by the RFC Editor
that have been included in the XML file as comments marked as
follows:
<!-- [rfced] ... -->
These questions will also be sent in a subsequent email.
* Changes submitted by coauthors
Please ensure that you review any changes submitted by your
coauthors. We assume that if you do not speak up that you
agree to changes submitted by your coauthors.
* Content
Please review the full content of the document, as this cannot
change once the RFC is published. Please pay particular attention to:
- IANA considerations updates (if applicable)
- contact information
- references
* Copyright notices and legends
Please review the copyright notice and legends as defined in
RFC 5378 and the Trust Legal Provisions
(TLP – https://trustee.ietf.org/license-info).
* Semantic markup
Please review the markup in the XML file to ensure that elements of
content are correctly tagged. For example, ensure that <sourcecode>
and <artwork> are set correctly. See details at
<https://authors.ietf.org/rfcxml-vocabulary>.
* Formatted output
Please review the PDF, HTML, and TXT files to ensure that the
formatted output, as generated from the markup in the XML file, is
reasonable. Please note that the TXT will have formatting
limitations compared to the PDF and HTML.
Submitting changes
------------------
To submit changes, please reply to this email using ‘REPLY ALL’ as all
the parties CCed on this message need to see your changes. The parties
include:
* your coauthors
* rfc-edi...@rfc-editor.org (the RPC team)
* other document participants, depending on the stream (e.g.,
IETF Stream participants are your working group chairs, the
responsible ADs, and the document shepherd).
* auth48archive@rfc-editor.org, which is a new archival mailing list
to preserve AUTH48 conversations; it is not an active discussion
list:
* More info:
https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc
* The archive itself:
https://mailarchive.ietf.org/arch/browse/auth48archive/
* Note: If only absolutely necessary, you may temporarily opt out
of the archiving of messages (e.g., to discuss a sensitive matter).
If needed, please add a note at the top of the message that you
have dropped the address. When the discussion is concluded,
auth48archive@rfc-editor.org will be re-added to the CC list and
its addition will be noted at the top of the message.
You may submit your changes in one of two ways:
An update to the provided XML file
— OR —
An explicit list of changes in this format
Section # (or indicate Global)
OLD:
old text
NEW:
new text
You do not need to reply with both an updated XML file and an explicit
list of changes, as either form is sufficient.
We will ask a stream manager to review and approve any changes that seem
beyond editorial in nature, e.g., addition of new text, deletion of text,
and technical changes. Information about stream managers can be found in
the FAQ. Editorial changes do not require approval from a stream manager.
Approving for publication
--------------------------
To approve your RFC for publication, please reply to this email stating
that you approve this RFC for publication. Please use ‘REPLY ALL’,
as all the parties CCed on this message need to see your approval.
Files
-----
The files are available here:
https://www.rfc-editor.org/authors/rfc9769.xml
https://www.rfc-editor.org/authors/rfc9769.html
https://www.rfc-editor.org/authors/rfc9769.pdf
https://www.rfc-editor.org/authors/rfc9769.txt
Diff file of the text:
https://www.rfc-editor.org/authors/rfc9769-diff.html
https://www.rfc-editor.org/authors/rfc9769-rfcdiff.html (side by side)
Diff of the XML:
https://www.rfc-editor.org/authors/rfc9769-xmldiff1.html
Tracking progress
-----------------
The details of the AUTH48 status of your document are here:
https://www.rfc-editor.org/auth48/rfc9769
Please let us know if you have any questions.
Thank you for your cooperation,
RFC Editor
--------------------------------------
RFC9769 (draft-ietf-ntp-interleaved-modes-08)
Title : NTP Interleaved Modes
Author(s) : M. Lichvar, A. Malhotra
WG Chair(s) : Dieter Sibold, Karen O'Donoghue
Area Director(s) : Erik Kline, Éric Vyncke
--
auth48archive mailing list -- auth48archive@rfc-editor.org
To unsubscribe send an email to auth48archive-le...@rfc-editor.org
