Hi, Erik. Thank you for the approval! So noted. Apologies for directing our emails to Éric Vyncke instead of to you.
https://www.rfc-editor.org/auth48/rfc9760 We will prepare this document for publication shortly. Thanks again! RFC Editor/lb > On May 13, 2025, at 2:28 PM, Erik Kline <ek.i...@gmail.com> wrote: > > The AUTH48 diff looks good to me! > > Thanks all! > > On Thu, May 8, 2025 at 11:43 AM Lynne Bartholomew > <lbartholo...@staff.rfc-editor.org> wrote: > 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
