Hello Miroslav, Per your comment in GitHub, we have merged the updates.
Please review the XML file and its TXT, HTML, and PDF outputs, and let us know if any changes are required or if you approve the RFC for publication. We consider this your final assent that the document is ready for publication. To request changes or approve your RFC for publication, please reply to this email. Please use ‘REPLY ALL’, as all the parties CCed on this message need to see your approval. XML file: https://www.rfc-editor.org/authors/rfc10030.xml Output files: https://www.rfc-editor.org/authors/rfc10030.txt https://www.rfc-editor.org/authors/rfc10030.html https://www.rfc-editor.org/authors/rfc10030.pdf Comprehensive diff file of the text: https://www.rfc-editor.org/authors/rfc10030-diff.html https://www.rfc-editor.org/authors/rfc10030-rfcdiff.html (side by side) For the Final Review status of this document, please see: https://queue.rfc-editor.org/final-review/rfc10030 Best regards, Karen Moore RFC Production Center > On Aug 4, 2026, at 7:40 AM, RFC Editor via auth48archive > <[email protected]> wrote: > > 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] -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
