Hello Lynne, Here are answers to your questions:
1. The "ISPCS" in this reference was a cut and paste error. The reference is intended to be [RFC2026]. This reference was added at the request of one of the reviewers. I do not have any objection to removing the reference and entire sentence containing it. 1. I agree with changing to timeTransmitter Only Clock in all three instances. 1. It should be Unicast discovery, i.e. the d in discovery is not capitalized. Thanks for catching these inconsistencies. Regards, Doug ________________________________ From: Lynne Bartholomew <lbartholo...@staff.rfc-editor.org> Sent: Tuesday, April 1, 2025 12:02 PM To: Doug Arnold <doug.arn...@meinberg-usa.com> Cc: rfc-edi...@rfc-editor.org <rfc-edi...@rfc-editor.org>; heiko.gerst...@meinberg.de <heiko.gerst...@meinberg.de>; tictoc-...@ietf.org <tictoc-...@ietf.org>; tictoc-cha...@ietf.org <tictoc-cha...@ietf.org>; ek.i...@gmail.com <ek.i...@gmail.com>; auth48archive@rfc-editor.org <auth48archive@rfc-editor.org> Subject: Re: AUTH48: RFC-to-be 9760 <draft-ietf-tictoc-ptp-enterprise-profile-28> for your review Hi, Doug. Thank you for your review and reply! A few follow-up items for you: 1. Apologies if our question 9) was unclear. > <!-- [rfced] Section 4: "ISPCS" (International Symposium on > Precision Clock Synchronization) does not appear to be relevant to > RFC 2026. May we remove the abbreviation from this sentence, or are > some words or an additional citation missing? > > Original: > See ISPCS [RFC2026] for information on IETF > applicability statements. --> Your reply: > We believe the link to the reference is wrong. You are correct, there is no > relationship to RFC2026, the link should have pointed to the [ISPCS] > reference (which is listed right above the RFC2026 reference in the > Informative References section. Because the ISPCS reference does not discuss IETF applicability statements, we had initially intended to suggest removing "ISPCS" from the sentence. However, on closer examination of the text, we cannot determine how this sentence is relevant to this document, because we don't see any discussion of the Internet Standards Process. The title of RFC 2026 is "The Internet Standards Process -- Revision 3", and RFC 2026 doesn't mention PTP. We see a citation for the ISPCS page three paragraphs later. If the "See ISPCS [RFC2026]" sentence isn't pertinent, would it be appropriate to remove it? If not, please clarify this text. 2. Apologies for not noticing this earlier: The change to "timeReceiver only clock" per your reply to part of our question 26) -- > "timeReceiver only clock". Change all three instances to this. -- results in "timeTransmitter Clock" and "timeReceiver Clock" but "timeReceiver only clock". May we change to "timeReceiver Only Clock" in running text? 3. Apologies for missing this earlier as well: Which is preferred -- "Unicast Discovery" or "Unicast discovery"? = = = = = The latest files are posted here. Please refresh your browser: https://www.rfc-editor.org/authors/rfc9760.txt https://www.rfc-editor.org/authors/rfc9760.pdf https://www.rfc-editor.org/authors/rfc9760.html https://www.rfc-editor.org/authors/rfc9760.xml https://www.rfc-editor.org/authors/rfc9760-diff.html https://www.rfc-editor.org/authors/rfc9760-rfcdiff.html (side by side) https://www.rfc-editor.org/authors/rfc9760-auth48diff.html https://www.rfc-editor.org/authors/rfc9760-auth48rfcdiff.html (side by side) https://www.rfc-editor.org/authors/rfc9760-xmldiff1.html https://www.rfc-editor.org/authors/rfc9760-xmldiff2.html Thanks again! RFC Editor/lb > On Mar 28, 2025, at 6:33 AM, Doug Arnold > <doug.arnold=40meinberg-usa....@dmarc.ietf.org> wrote: > > RFC editor, > > Thanks for finding lots of nits. Here are answers from the authors to your > questions, > > 1) single initial is fine for us > 2) confirm that we do not need to change the document > 3) The relevant part in [Estrela_and_Bonebakker] is this: > " Unfortunately, this option is not scalable, because all clients from all > clusters will be continuously receiving foreign packets at user space, only > to be silently discarded. " > So we agree that there is no number / specific value mentioned. The >99% have > been chosen to express that the overwhelming majority of all received packets > are affected. We would keep it this way. > 4) We agree with the suggested change > 5) We agree with the proposed change, an alternate timeTransmitter can become > the best TimeTransmitter at any time, so „that“ is more accurate than „which“. > 6) We agree with the suggested change > 7) We agree with the suggested change > 8) No objections > 9) We believe the link to the reference is wrong. You are correct, there is > no relationship to RFC2026, the link should have pointed to the [ISPCS] > reference (which is listed right above the RFC2026 reference in the > Informative References section. > 10) All references are valid for IEEE 1588-2019. > 11) We believe the intention was to avoid the impression that the ITU-T > reference is the one and only document that explains network asymmetry. That > is why the „for example“ has been chosen. As this topic is out of scope, we > did not want to research and provide an extensive list of documents and just > wanted to give an example. I would be OK with removing this reference, if the > „for example“ is not acceptable. > 12) We agree with the suggested change > 13) We agree with the suggested change > 14) We agree with the proposed text ("such as delay attacks, packet > interception attacks, and packet manipulation attacks“) > 15) We agree with the proposed text ("the timeTransmitter ports' preferred > message period") > 16) We believe it must be changed to „Announce Receipt Timeout Interval“ > 17) "Syntonize" i.e., frequency synchronization is used purposely to > distinguish it from time synchronization, which we often shorten to simply > synchronization. > 18) We suggest changing "is not set to All 1s" to "does not have all bits set > to 1". > 19) We agree with the proposed change, i.e., to make it a list > 20) This is not a direct quote from IEEE 1588. We agree with the rearranged > format. > 21) We agree with the change > 22) We agree with the change > 23) We agree with the change > 24) We agree with the change and prefer the "suggested" change rather than > the "alternatively" change > 25) Native management is the term used informally in the PTP community, but > the term does appear in IEEE 1588-2019 or IEEE 1588-2008. Both versions of > IEEE 1588 refer to it as "PTP manange messages", so the word native should be > removed from our draft. Also "a traditional time tranfer such as NTP" should > be changed to simply "NTP". > 26) We prefer the following: > "Alternate timeTransmitter" > "Best timeTransmitter" except when used in the term "Best TimeTransmitter > Clock Algorithm > "End-to-End delay measurement" > "enterprise" used generally, i.e. not referring to the "Enterprise Profile" > "Enterprise Profile clock" > "Peer-to-Peer delay measurement mechanism" > "Preferred timeTransmitter" > "PTP clock" > "PTP domain" > "PTP management messages" > "PTP Networks" > "PTP Node" > "PTP Port" is correct > "timeReceiver" unless it is the beginning of a sentence. > "timeReceiver only clock". Change all three instances to this. > "unicast message negotiation" > > Let me know if you have further questions. > > Regards, > DougFrom: rfc-edi...@rfc-editor.org <rfc-edi...@rfc-editor.org> > Sent: Monday, March 24, 2025 5:11 PM > To: Doug Arnold <doug.arn...@meinberg-usa.com>; heiko.gerst...@meinberg.de > <heiko.gerst...@meinberg.de> > Cc: rfc-edi...@rfc-editor.org <rfc-edi...@rfc-editor.org>; > tictoc-...@ietf.org <tictoc-...@ietf.org>; tictoc-cha...@ietf.org > <tictoc-cha...@ietf.org>; ek.i...@gmail.com<ek.i...@gmail.com>; > ek.i...@gmail.com <ek.i...@gmail.com>; auth48archive@rfc-editor.org > <auth48archive@rfc-editor.org> > Subject: Re: AUTH48: RFC-to-be 9760 > <draft-ietf-tictoc-ptp-enterprise-profile-28> for your review > Authors, > > While reviewing this document during AUTH48, please resolve (as necessary) > the following questions, which are also in the XML file. > > > 1) <!-- [rfced] First-page header: Authors, we have updated both of your > names in > the first-page header to use a single initial rather than two > initials. Please let us know if you prefer to use two initials. Note that > Heiko's name was listed with a single initial in the first-page header of > RFC 5907. > > For more information about author names in the first-page header, please see > Section 4.1.1 of RFC 7322 ("RFC Style Guide"). > --> > > > 2) <!-- [rfced] We see the following warning in idnits output: > "There are 1 instance of lines with multicast IPv4 addresses in the > document. If these are generic example addresses, they should be changed > to use the 233.252.0.x range defined in RFC 5771" > > It appears that idnits confused multicast addresses with the PTP > primary IP address (for IPv4) listed in Section 6, but we want to > point out the idnits warning all the same. It appears that we don't > need to make any changes. Please review and confirm. > > Original: > The PTP primary IP address is > 224.0.1.129 for IPv4 and FF0X:0:0:0:0:0:0:181 for IPv6, where X can > be a value between 0x0 and 0xF. --> > > > 3) <!-- [rfced] Section 1: We could not find any instances of "%", > "99", "nine", "percent", "per cent", "per-cent", "cent", "discard", > "exceed", or "relevant" in [Estrela_and_Bonebakker]. Please confirm > that the text is correct and will be clear to readers when they > consult [Estrela_and_Bonebakker]. > > Original ("receving" and "exceded" have been corrected): > The > percent of PTP message that are discarded as irrelevant to the > receving node can exceded 99% (Estrela and Bonebakker > [Estrela_and_Bonebakker]). --> > > > 4) <!-- [rfced] Section 1: We find "and a few other ways" a bit > confusing. If the suggested text is not correct, please clarify the > text. > > Original: > It is possible to extend > the PTP standard with a PTP Profile by using the TLV mechanism of PTP > (see IEEE 1588-2019 [IEEE1588] subclause 13.4), defining an optional > Best TimeTransmitter Clock Algorithm and a few other ways. > > Suggested: > It is possible to extend > the PTP standard with a PTP Profile by using the TLV mechanism of PTP > (see [IEEE1588-2019], Subclause 13.4) or defining an optional Best > TimeTransmitter Clock Algorithm, among other techniques (which are > beyond the scope of this document). --> > > > 5) <!-- [rfced] Section 3: Does this definition indicate that a PTP > timeTransmitter Clock is never the Best timeTransmitter, or does it > indicate that some PTP timeTransmitter Clocks might not be the > Best timeTransmitter (in which case "which" should be "that")? > > Original: > * Alternate timeTransmitter: A PTP timeTransmitter Clock, which is > not the Best timeTransmitter, may act as a timeTransmitter with > the Alternate timeTransmitter flag set on the messages it sends. > > Possibly (updated to achieve parallelism in the list): > Alternate timeTransmitter: A PTP timeTransmitter Clock that is not > the Best timeTransmitter and therefore is used as an alternative > clock. It may act as a timeTransmitter with the Alternate > timeTransmitter flag set on the messages it sends. --> > > > 6) <!-- [rfced] Section 3: "timeTransmitter Clock properties of a > timeTransmitter Clock" reads oddly. Should the wording be different? > If the suggested text is not correct, please clarify. > > Original: > * Announce message: Contains the timeTransmitter Clock properties of > a timeTransmitter Clock. Used to determine the Best > TimeTransmitter. > > Suggested: > Announce message: Contains the properties of a given > timeTransmitter Clock. The information is used to determine the > Best TimeTransmitter. --> > > > 7) <!-- [rfced] Section 3: This sentence does not parse. If the > suggested text is not correct, please clarify "and does not set". > > Original: > * Rogue timeTransmitter: A clock with a PTP Port in the > timeTransmitter state, even though it should not be in the > timeTransmitter state according to the Best TimeTransmitter Clock > Algorithm, and does not set the Alternate timeTransmitter flag. > > Suggested: > Rogue timeTransmitter: A clock that has a PTP Port in the > timeTransmitter state - even though it should not be in the > timeTransmitter state according to the Best TimeTransmitter Clock > Algorithm - and that does not set the Alternate timeTransmitter > flag. --> > > > 8) <!-- [rfced] Section 3: Because this list was ordered alphabetically > except for the "TimeTransmitter Clock:" entry, we moved the > "TimeTransmitter Clock:" entry so that it appears between > "TimeReceiver Only clock:" and "TLV:". Please let us know any > objections. > > Original: > ... > * IEEE 1588: The timing and synchronization standard which defines > PTP, and describes the node, system, and communication properties > necessary to support PTP. > > * TimeTransmitter Clock: a clock with at least one PTP Port in the > timeTransmitter state. > > * NTP: Network Time Protocol, defined by RFC 5905, see RFC 5905 > [RFC5905] > ... > * TimeReceiver Only clock: An Ordinary Clock which cannot become a > timeTransmitter Clock. > > * TLV: Type Length Value, a mechanism for extending messages in > networked communications. > ... > > Currently: > ... > IEEE 1588: The timing and synchronization standard that defines PTP > and describes the node, system, and communication properties > necessary to support PTP. > > NTP: Network Time Protocol, defined by [RFC5905]. > ... > TimeReceiver Only clock: An Ordinary Clock that cannot become a > timeTransmitter Clock. > > TimeTransmitter Clock: A clock with at least one PTP Port in the > timeTransmitter state. > > TLV: Type Length Value. A mechanism for extending messages in > networked communications. > ... --> > > > 9) <!-- [rfced] Section 4: "ISPCS" (International Symposium on > Precision Clock Synchronization) does not appear to be relevant to > RFC 2026. May we remove the abbreviation from this sentence, or are > some words or an additional citation missing? > > Original: > See ISPCS [RFC2026] for information on IETF > applicability statements. --> > > > 10) <!-- [rfced] Sections 5, 6, 8, 9, 12, and 14: Because it appears > that, per citations in Sections 1 and 17, the instances of > "IEEE 1588 [IEEE1588]" also refer to IEEE 1588-2019, we updated these > sentences accordingly and also changed the citation string from > "[IEEE1588]" to "[IEEE1588-2019]". > > Side topic: Please note that because IEEE 1588-2019 is behind a > paywall or login setup, we cannot verify the specified annexes or > subclauses. Please review our citation-string updates carefully, and > let us know if anything is incorrect. > > Original: > This PTP Profile MUST operate only in networks characterized by UDP > RFC 768 [RFC0768] over either IPv4 RFC 791 [RFC0791] or IPv6 RFC 8200 > [RFC8200], as described by Annexes C and D in IEEE 1588 [IEEE1588] > respectively. > ... > The different IPv6 address options > are explained in IEEE 1588 IEEE 1588 [IEEE1588] Annex D, Section D.3. > ... > TimeTransmitter Clocks MUST obey the standard Best TimeTransmitter > Clock Algorithm from IEEE 1588 [IEEE1588]. > ... > See IEEE 1588 > [IEEE1588], subClause 11.2. > ... > Management messages intended > for a specific clock, i.e. the IEEE 1588 [IEEE1588] defined attribute > targetPortIdentity.clockIdentity is not set to All 1s, MUST be sent > as a unicast message. > ... > Clocks operating in the Enterprise Profile will interoperate with > clocks operating in the Default Profile described in IEEE 1588 > [IEEE1588] Annex I.3. > > Currently: > This PTP Profile MUST operate only in networks characterized by UDP > [RFC0768] over either IPv4 [RFC0791] or IPv6 [RFC8200], as described > by Annexes C and D of [IEEE1588-2019], respectively. > ... > The different IPv6 address options > are explained in [IEEE1588-2019], Annex D, Section D.3. > ... > TimeTransmitter Clocks MUST obey the standard Best TimeTransmitter > Clock Algorithm as defined in [IEEE1588-2019]. > ... > See [IEEE1588-2019], > Subclause 11.2. > ... > Management messages intended > for a specific clock, i.e., where the > targetPortIdentity.clockIdentity attribute (defined in > [IEEE1588-2019]) is not set to All 1s, MUST be sent as a unicast > message. > ... > Clocks operating in the Enterprise Profile will interoperate with > clocks operating in the Default Profile described in [IEEE1588-2019], > Annex I.3. --> > > > 11) <!-- [rfced] Section 5: We found this "for example" sentence a bit > misleading in the context of network asymmetry being outside the > scope of this document. May we clarify by updating as suggested? > > Original (the previous sentence is included for context): > The details of > network asymmetry are outside the scope of this document. See for > example, ITU-T G.8271 [G8271]. > > Suggested: > See ITU-T G.8271 [G8271] for details regarding network asymmetry. --> > > > 12) <!-- [rfced] Section 6: Because this sentence indicates a > requirement and we see that PTP messages can be either event > multicast messages or general multicast messages, would you like to > be more specific and confirm that "UDP port 320" is correct here? > > Original: > Announce messages MUST be sent as multicast messages (UDP port 320) > to the PTP primary address. > > Suggested: > Announce messages MUST also be sent as PTP general multicast > messages (UDP port 320) to the PTP primary address. --> > > > 13) <!-- [rfced] Section 6: We could not find a dictionary definition of > "ensemble(d)" used as a verb. If the suggested text is not correct, > please clarify. > > Original: > Redundant sources of timing can be ensembled, and/or > compared to check for faulty timeTransmitter Clocks. > > Suggested: > To check for faulty timeTransmitter Clocks, redundant sources of > timing can be evaluated as an ensemble and/or compared individually. --> > > > 14) <!-- [rfced] Section 6: Does "such as delay attacks, packet > interception / manipulation attacks" mean "such as delay attacks, > packet interception attacks, and packet manipulation attacks" or > something else? Please clarify the text. > > Original: > Security problems include on-path attacks such as > delay attacks, packet interception / manipulation attacks. --> > > > 15) <!-- [rfced] Section 7: Does "the timeTransmitter ports preferred > message period" mean "the timeTransmitter ports' preferred message > period", "the preferred message period for timeTransmitter ports", > or something else? Please clarify. > > Original: > The logMessageInterval carried in the unicast Delay Response message > MAY be set to correspond to the timeTransmitter ports preferred > message period, rather than 7F, which indicates message periods are > to be negotiated. --> > > > 16) <!-- [rfced] Section 9: Please confirm that "Announce Time Out > Interval" is correct and is distinct from "Announce Receipt Timeout > Interval" as mentioned in Section 7. > > Original: > TimeReceivers will > continue to recognize a Best TimeTransmitter for the duration of the > Announce Time Out Interval. --> > > > 17) <!-- [rfced] Section 10: Please confirm that "syntonize to" and not > "synchronize to" is correct here. Does it mean "to put in resonance" > or "tune" per <https://www.merriam-webster.com/dictionary/syntonize>? > We ask because we see "synchronize to" used elsewhere in this > document. > > Original: > Transparent Clocks which syntonize to the timeTransmitter Clock might > need to maintain separate clock rate offsets for each of the > supported domains. --> > > > 18) <!-- [rfced] Section 12: Is "All 1s" an alphanumeric setting (i.e., > "targetPortIdentity.clockIdentity = All 1s") or some other format > (perhaps a broadcast address)? If it is some other format, would it > be helpful to update the text to something along the lines of our > "Possibly" example below? > > Original: > Management messages intended > for a specific clock, i.e. the IEEE 1588 [IEEE1588] defined attribute > targetPortIdentity.clockIdentity is not set to All 1s, MUST be sent > as a unicast message. > > Possibly (using the all-1s MAC-address format mentioned in the > definition of "Clock Identity" in Section 3): > Management messages intended > for a specific clock, i.e., where the > targetPortIdentity.clockIdentity attribute (defined in > [IEEE1588-2019]) is not set to all 1s (e.g., FF-FF-FF-FF-FF-FF), > MUST be sent as a unicast message. --> > > > 19) <!-- [rfced] Section 13: As originally written, it was not clear > which options must not be used. We updated the text to use a list. > Please review, and let us know if anything is incorrect. For > example, if "Unicast discovery, or unicast negotiation" does not > belong in the list, please provide the missing words for the > incomplete sentence. > > Original: > Clocks operating in the Enterprise Profile MUST NOT use: Peer-to-Peer > timing for delay measurement, Grandmaster Clusters, The Alternate > TimeTransmitter option, Alternate Timescales. Unicast discovery, or > unicast negotiation. > > Currently: > Clocks operating in the Enterprise Profile MUST NOT use the > following: > > * Peer-to-Peer timing for delay measurement > > * Grandmaster Clusters > > * The Alternate TimeTransmitter option > > * Alternate Timescales > > * Unicast discovery > > * Unicast negotiation --> > > > 20) <!-- [rfced] Section 15: The indented text below was originally tagged as > <artwork>; we updated to use <dl> for the first four lines and <t> for > the last two sentences. Note that this text is no longer indented. > > Is this text a direct quote from IEEE 1588? If so, we will add > <blockquote>. We are not able to access IEEE 1588 to check this. > > Also, we see this note on > <https://datatracker.ietf.org/doc/draft-ietf-tictoc-ptp-enterprise-profile/writeup/>: > > "This is the final document output from TICTOC. After this, I > expect to close the working group. NTP has been rechartered to > encompass work on several time sync protocols, and future work > can be brought there (or dispatched therefrom)." > > Please confirm that <https://datatracker.ietf.org/wg/tictoc/documents> is the > best URL to be used in the text below since it is specific to the TICTOC > Working Group, which is closing. Would it be helpful to mention the URL for > the NTP Working Group (https://datatracker.ietf.org/wg/ntp/documents/)? > Please review and let us know if any updates are needed. > > Original: > The IEEE 1588 standard requires that all PTP Profiles provide the > following identifying information. > > PTP Profile: > Enterprise Profile > Profile number: 1 > Version: 1.0 > Profile identifier: 00-00-5E-01-01-00 > > This PTP Profile was specified by the IETF > > A copy may be obtained at > https://datatracker.ietf.org/wg/tictoc/documents > > Currently: > The IEEE 1588 standard requires that all PTP Profiles provide the > following identifying information. > > PTP Profile: Enterprise Profile > Profile number: 1 > Version: 1.0 > Profile identifier: 00-00-5E-01-01-00 > > This PTP Profile was specified by the IETF. > > A copy may be obtained at <https://datatracker.ietf.org/wg/tictoc/ > documents>. > --> > > > 21) <!-- [rfced] [IEEE1588]: We updated the URL for this reference to > point to the IEEExplore page for this standard. Please let us know > any objections. > > Original: > [IEEE1588] Institute of Electrical and Electronics Engineers, "IEEE > std. 1588-2019, "IEEE Standard for a Precision Clock > Synchronization for Networked Measurement and Control > Systems."", November 2019, <https://www.ieee.org>. > > Currently: > [IEEE1588-2019] > IEEE, "IEEE Standard for a Precision Clock Synchronization > for Networked Measurement and Control Systems", IEEE > Std 1588-2019, DOI 10.1109/IEEESTD.2020.9120376, June > 2020, <https://ieeexplore.ieee.org/document/9120376>. --> > > > 22) <!-- [rfced] [IEEE1588g]: We updated the URL for this reference to > point to the IEEExplore page for this standard. Please let us know > any objections. > > Original: > [IEEE1588g] > Institute of Electrical and Electronics Engineers, "IEEE > std. 1588g-2022, "IEEE Standard for a Precision Clock > Synchronization Protocol for Networked Measurement and > Control Systems Amendment 2: Master-Slave Optional > Alternative Terminology"", December 2022, > <https://www.ieee.org>. > > Currently: > [IEEE1588g] > IEEE, "IEEE Standard for a Precision Clock Synchronization > Protocol for Networked Measurement and Control Systems > Amendment 2: Master-Slave Optional Alternative > Terminology", IEEE Std 1588g-2022, > DOI 10.1109/IEEESTD.2023.10070440, March 2023, > <https://ieeexplore.ieee.org/document/10070440>. --> > > > 23) <!-- [rfced] [G8271]: Because the original listed date for this > reference is March 2020, we updated the title to match the 2020 > version, which is listed as "In force" on > <https://www.itu.int/rec/t-rec-g.8271/en>. We also updated the URL > accordingly. Please let us know any objections. > > Original: > [G8271] International Telecommunication Union, "ITU-T G.8271/ > Y.1366, "Time and Phase Synchronization Aspects of Packet > Networks"", March 2020, <https://www.itu.int>. > > Currently: > [G8271] ITU-T, "Time and phase synchronization aspects of > telecommunication networks", ITU-T > Recommendation G.8271/Y.1366, March 2020, > <https://www.itu.int/rec/T-REC-G.8271-202003-I/en>. --> > > > 24) <!-- [rfced] [ISPCS]: The provided URL steers to the page for > ISPCS 2024. May we update this listing to reflect the 2017 > conference? > > Original: > [ISPCS] Arnold, D., "Plugfest Report", October 2017, > <https://www.ispcs.org>. > > Suggested: > [ISPCS] Arnold, D. and K. Harris, "Plugfest", Proceedings of the > IEEE International Symposium on Precision Clock > Synchronization for Measurement, Control, and > Communication (ISPCS), August 2017, > <https://2017.ispcs.org/plugfest>. > > Alternatively (if "2017" is no longer correct or applicable): > [ISPCS] Arnold, D., "Plugfest", Proceedings of the IEEE > International Symposium on Precision Clock > Synchronization for Measurement, Control, & > Communication (ISPCS), October 2024, > <https://www.ispcs.org>. --> > > > 25) <!-- [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. > > We appreciate your efforts to use alternatives to "master" and > "slave" as noted in Section 1. > > Please consider whether the following should be updated: > > "native" ("PTP native management messages") > Perhaps "PTP innate management messages" > > "traditional" ("... a traditional time transfer such as NTP") * > Perhaps "a long-established time transfer such as NTP" > > * Please consider whether "tradition" could be updated for clarity. > While the NIST website (https://www.nist.gov/nist-research-library/ > nist-technical-series-publications-author-instructions#table1) > indicates that this term is potentially biased, it is also ambiguous. > "Tradition" is a subjective term, as it is not the same for everyone. --> > > > 26) <!-- [rfced] The following terms appear to be used inconsistently in > this document. Please let us know which form is preferred. > > Alternate timeTransmitter (3 instances / > Alternate TimeTransmitter (1 instance) > ("Alternate timeTransmitter flag", "Alternate TimeTransmitter > option") > > Best timeTransmitter (2 instances) / > Best TimeTransmitter (3 instances) > (used generally, e.g., "the Best timeTransmitter, ...", "the Best > TimeTransmitter. ...") > > End-to-End Delay measurement (1 instance) / > End-to-End delay measurement (3 instances) > > Enterprise (1 instance) / enterprise (3 instances) > (used generally, e.g., "Enterprise > information system environment", "enterprise networks") > > Enterprise Profile Clock (1 instance) / > Enterprise Profile clock (1 instance) > > Peer-to-Peer delay measurement mechanism (2 instances) / > Peer-to-peer measurement mechanism (1 instance) > > Preferred TimeTransmitter (1 instance) / > Preferred timeTransmitter (2 instances) > > PTP Clock (3 instances) / PTP clock (3 instances)* > > PTP Domain (3 instances) / PTP domain (9 instances)* > > PTP Management messages (1 instance) / > management messages (1 instance) / > PTP native management messages (1 instance) > > PTP Networks (1 instance) / PTP networks (1 instance)* > > PTP Node (2 instances) / PTP node (5 instances)* > > * We see that "PTP Port" is used consistently. > > TimeReceiver (4 instances) / timeReceiver (approx. 14 instances) > (used generally, e.g., "domains, TimeReceivers SHOULD", > "then the timeReceiver MUST NOT"; please review, and let us know > if any changes are needed) > > TimeReceiver Only clock (1 instance) / > TimeReceiver Only Clock (1 instance) / > timeReceiver Only Clock (1 instance) > > Unicast Message Negotiation / unicast negotiation (in text) --> > > > Thank you. > > RFC Editor/lb/rv > > > > On Mar 24, 2025, at 2:08 PM, rfc-edi...@rfc-editor.org wrote: > > *****IMPORTANT***** > > Updated 2025/03/24 > > 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/rfc9760.xml > https://www.rfc-editor.org/authors/rfc9760.html > https://www.rfc-editor.org/authors/rfc9760.pdf > https://www.rfc-editor.org/authors/rfc9760.txt > > Diff file of the text: > https://www.rfc-editor.org/authors/rfc9760-diff.html > https://www.rfc-editor.org/authors/rfc9760-rfcdiff.html (side by side) > > Diff of the XML: > https://www.rfc-editor.org/authors/rfc9760-xmldiff1.html > > > Tracking progress > ----------------- > > The details of the AUTH48 status of your document are here: > https://www.rfc-editor.org/auth48/rfc9760 > > Please let us know if you have any questions. > > Thank you for your cooperation, > > RFC Editor > > -------------------------------------- > RFC9760 (draft-ietf-tictoc-ptp-enterprise-profile-28) > > Title : Enterprise Profile for the Precision Time Protocol With > Mixed Multicast and Unicast messages > Author(s) : D. Arnold, H. Gerstung > WG Chair(s) : Yaakov (J) Stein, 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
