Hi, Éric. Please note that this document awaits your approval:
https://www.rfc-editor.org/auth48/rfc9760 Please see the email below re. removing the citation and reference listing for RFC 2026, and let us know if you approve. Thank you! RFC Editor/lb > On May 5, 2025, at 9:15 AM, Lynne Bartholomew > <lbartholo...@staff.rfc-editor.org> wrote: > > Dear Heiko, > > We have noted your approval on the AUTH48 status page: > > https://www.rfc-editor.org/auth48/rfc9760 > > If we can receive approval from Éric, we will move this document forward for > publication. > > Thank you! > > RFC Editor/lb > >> On May 1, 2025, at 11:59 PM, Heiko Gerstung <heiko.gerst...@meinberg.de> >> wrote: >> >> I also approve the document, thank you! >> >> Regards, >> Heiko >> -- >> Heiko Gerstung | Managing Director >> T: +49 (0)5281 9309-404 | LinkedIn Profile | Twitter >> heiko.gerst...@meinberg.de >> >> MEINBERG® The Synchronization Experts >> Meinberg Funkuhren GmbH & Co. KG >> Lange Wand 9 | 31812 Bad Pyrmont | Germany >> Web: https://www.meinberg.de/ | https://www.meinbergglobal.com/ | LinkedIn >> >> Amtsgericht Hannover 17HRA 100322 >> Geschäftsführer/Management: Natalie Meinberg, Werner Meinberg, Andre >> Hartmann, Heiko Gerstung >> >> Do not miss our Time Synchronization Blog: >> http://blog.meinbergglobal.com >> >>> Am 01.05.2025 um 18:43 schrieb Lynne Bartholomew >>> <lbartholo...@staff.rfc-editor.org>: >>> >>> Apologies for the duplicate email; hiccup on our end. >>> >>>> On May 1, 2025, at 9:41 AM, Lynne Bartholomew >>>> <lbartholo...@staff.rfc-editor.org> wrote: >>>> >>>> Dear Heiko and *Éric, >>>> >>>> We do not believe that we have heard from you regarding this document's >>>> readiness for publication. >>>> >>>> Heiko, please let us know whether further changes are required for this >>>> document or you approve it for publication. >>>> >>>> * Éric, please see our note below re. removing the citation and reference >>>> listing for RFC 2026, and let us know if you approve. >>>> >>>> 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-lastdiff.html >>>> https://www.rfc-editor.org/authors/rfc9760-lastrfcdiff.html (side by side) >>>> >>>> https://www.rfc-editor.org/authors/rfc9760-xmldiff1.html >>>> https://www.rfc-editor.org/authors/rfc9760-xmldiff2.html >>>> >>>> The AUTH48 status page is here: >>>> >>>> https://www.rfc-editor.org/auth48/rfc9760 >>>> >>>> Thank you! >>>> >>>> RFC Editor/lb >>>> >>>>> On Apr 22, 2025, at 3:39 PM, Lynne Bartholomew >>>>> <lbartholo...@staff.rfc-editor.org> wrote: >>>>> >>>>> Hi, Doug. So noted (https://www.rfc-editor.org/auth48/rfc9760). >>>>> >>>>> Thank you! >>>>> >>>>> RFC Editor/lb >>>>> >>>>>> On Apr 21, 2025, at 2:49 PM, Doug Arnold <doug.arn...@meinberg-usa.com> >>>>>> wrote: >>>>>> >>>>>> Hello Lynne, >>>>>> >>>>>> I approve it for publication. >>>>>> >>>>>> Douglas Arnold >>>>>> >>>>>> From: Lynne Bartholomew <lbartholo...@staff.rfc-editor.org> >>>>>> Sent: Monday, April 21, 2025 4:06 PM >>>>>> To: Doug Arnold <doug.arn...@meinberg-usa.com>; >>>>>> heiko.gerst...@meinberg.de <heiko.gerst...@meinberg.de>; >>>>>> tictoc-...@ietf.org <tictoc-...@ietf.org> >>>>>> Cc: rfc-edi...@rfc-editor.org <rfc-edi...@rfc-editor.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: *[AD] Re: AUTH48: RFC-to-be 9760 >>>>>> <draft-ietf-tictoc-ptp-enterprise-profile-28> for your review >>>>>> Dear Doug, Heiko, and AD (Erik or Éric), >>>>>> >>>>>> We do not believe that we have heard from you regarding this document's >>>>>> readiness for publication. >>>>>> >>>>>> Doug and Heiko, please let us know whether further changes are required >>>>>> for this document or you approve it for publication. >>>>>> >>>>>> Erik or Éric, please see our note below re. removing the citation and >>>>>> reference listing for RFC 2026, and let us know if you approve. >>>>>> >>>>>> The AUTH48 status page is here: >>>>>> >>>>>> https://www.rfc-editor.org/auth48/rfc9760 >>>>>> >>>>>> Thank you! >>>>>> >>>>>> RFC Editor/lb >>>>>> >>>>>>> On Apr 9, 2025, at 9:50 AM, Lynne Bartholomew >>>>>>> <lbartholo...@staff.rfc-editor.org> wrote: >>>>>>> >>>>>>> Hi, Doug and *AD. >>>>>>> >>>>>>> Doug, thank you for your reply to our additional questions! We have >>>>>>> updated the document accordingly. >>>>>>> >>>>>>> * AD (Erik or Éric), because a reviewer had requested earlier that a >>>>>>> citation and reference listing for RFC 2026 be added in this document, >>>>>>> please let us know if you approve the removal of the citation and >>>>>>> reference listing (the second sentence in Section 4, per Doug's latest >>>>>>> note below. >>>>>>> >>>>>>> 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-lastdiff.html >>>>>>> https://www.rfc-editor.org/authors/rfc9760-lastrfcdiff.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 Apr 3, 2025, at 3:07 PM, Doug Arnold <doug.arn...@meinberg-usa.com> >>>>>>>> wrote: >>>>>>>> >>>>>>>> Hello Lynne, >>>>>>>> >>>>>>>> Here are answers to your questions: >>>>>>>> >>>>>>>> • 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. >>>>>>>> >>>>>>>> • I agree with changing to timeTransmitter Only Clock in all three >>>>>>>> instances. >>>>>>>> >>>>>>>> • It should be Unicast discovery, i.e. the d in discovery is not >>>>>>>> capitalized. >>>>>>>> >>>>>>>> Thanks for catching these inconsistencies. >>>>>>>> >>>>>>>> Regards, >>>>>>>> DougFrom: 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
