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
