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
