Authors,
While reviewing this document during Final Review, please resolve (as
necessary) the
following questions, which are also in GitHub issues
(see https://github.com/rfc-editor-drafts/FinalReview-rfc10030/issues).
1) <!--[rfced] Please note that the document title has been updated as
follows. "PTP" has been expanded per Section 3.6 of RFC 7322
("RFC Style Guide"). We did not expand "NTP" as it is marked as
"well known" on the Abbreviations List at
<https://rpc-wiki.rfc-editor.org/rpc/wiki/doku.php?id=abbrev_list>;
however, if you would like to expand it, please let us know.
Original:
NTP Over PTP
Current:
NTP over the Precision Time Protocol (PTP)
-->
2) <!-- [rfced] Please insert any keywords (beyond those that appear in
the title) for use on https://www.rfc-editor.org/search. -->
3) <!--[rfced] May we update this sentence for clarity as shown below
(e.g., update "growing" to "increases")?
Original:
The disadvantage of NTP is transmit timestamping rate growing
with the number of clients.
Perhaps:
The disadvantage of NTP is that the transmit timestamping rate
increases as the number of clients grows.
-->
4) <!--[rfced] To clarify what the numbers 3, 4, 1, and 2 refer to in this
sentence, may we add a citation to RFC 5905?
Original:
A new TLV is defined for PTP to contain NTP messages in the
NTP client (3), server (4), and symmetric modes (1 and 2).
Perhaps:
Original:
A new TLV is defined for PTP to contain NTP messages in the
NTP client (3), server (4), and symmetric modes (1 and 2) (see [RFC5905]).
-->
5) <!-- [rfced] We have updated the instances of [[TBD]]. Please
review carefully, as they have been updated to reflect different values.
Section 2 - Original:
* organizationSubType is [[TBD]]
Current:
* organizationSubType is 0x01
Section 3 - Original:
| Type = [[TBD]] | Length |
Current
| Type = 0x010A | Length |
Section 5.2 - Original:
| [[TBD]] | Network Correction | [[this memo]] |
Current:
| 0x010A | Network Correction | [[this memo]] |
-->
6) <!--[rfced] May we update this sentence for clarity by adding
parentheses as shown below?
Original:
The receive duration included in the NTP correction cancels out the
transposition of PTP receive timestamp corresponding to the beginning
of the reception to NTP receive timestamp corresponding to the end of
the reception.
Perhaps:
The receive duration included in the NTP correction cancels out the
transposition from the PTP receive timestamp (which corresponds to the
beginning of the reception) to the NTP receive timestamp (which
corresponds to the end of the reception).
-->
7) <!--[rfced] May we update this sentence to avoid the double negative
(i.e., "MUST NOT be corrected to not make")?
Original:
Root delay (DELTA) MUST NOT be corrected to not make the maximum
assumed error (root distance) dependent on accurate network
corrections.
Perhaps:
Root delay (DELTA) MUST NOT be corrected to ensure that the
maximum assumed error (root distance) remains independent of
network corrections.
-->
8) <!-- [rfced] FYI - We have added an expansion for the following abbreviation
per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review this and each
expansion in the document carefully to ensure correctness.
Network Interface Cards (NICs)
-->
9) <!--[rfced] Please review the "Inclusive Language" portion of the online
Style Guide <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.
-->
Thank you.
Karen Moore and Sandy Ginoza
RFC Production Center
On Aug 4, 2026, at 7:24 AM, [email protected] wrote:
*****IMPORTANT*****
RFC Author(s):
--------------
Your document has now entered Final Review (formerly AUTH48).
Final Review is being handled in GitHub as part of the GitHub pilot test
(see
https://www.rfc-editor.org/rpc/wiki/doku.php?id=rpc-github-phase-0-pilot-test).
Your document is available for review at:
https://github.com/rfc-editor-drafts/FinalReview-rfc10030
Please do the following:
a) accept your invitations to join the repo as collaborators.
b) see the README for details on the Final Review process:
https://github.com/rfc-editor-drafts/FinalReview-rfc10030/blob/Approved/README.md
c) review the edits in the RPC-edits pull request:
https://github.com/rfc-editor-drafts/FinalReview-rfc10030/pulls
d) address the issues:
https://github.com/rfc-editor-drafts/FinalReview-rfc10030/issues
Once the content is stable in GitHub, we will provide the updated XML file
and the output files for review and approval.
You and your coauthors are responsible for engaging other parties
(e.g., Contributors or Working Group) as necessary before providing
your approval.
Once the document has been reviewed and approved by all of the authors,
it will be published as an RFC. If an author is no longer available,
there are several remedies; see the Unavailable Authors section
(https://authors.ietf.org/rfc-publication-process#unavailable-authors).
Details on the status of your Final Review are here:
https://queue.rfc-editor.org/final-review/rfc10030/
Please let us know if you have any questions.
Thank you for your cooperation,
RFC Production Center
--
auth48archive mailing list -- [email protected]
To unsubscribe send an email to [email protected]
