Greetings again, Please note that the repo has been updated.
Repo: https://github.com/rfc-editor-drafts/FinalReview-rfc10030 Diff: https://github.com/rfc-editor-drafts/FinalReview-rfc10030/pull/12/changes Questions that need to be resolved: https://github.com/rfc-editor-drafts/FinalReview-rfc10030/issues Please let us know if you have any questions. Our apologies for the rocky start to Final Review. Thanks, Sandy Ginoza RFC Production Center > On Aug 4, 2026, at 1:03 PM, Sandy Ginoza <[email protected]> wrote: > > Greetings all, > > Apologies, but the repo we created is not working as expected. Please do NOT > review the document at this time. We will notify you (shortly) when you can > start your review. > > Thank you for your patience! > Sandy Ginoza > RFC Production Center > > >> On Aug 4, 2026, at 7:40 AM, [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]
